Beelink-Mini-MX-2G RTL8211F Ethernet TX fix
atsdai opened this issue · comments
Hi, I would like to provide the solution to the problem I had with my Beelink-Mini-MX-2G and help anyone who may have the same problem. The ethernet TX was not working properly.
I managed to fix it by converting the meson-gxbb-vega-s95-telos.dtb file to dts (https://stackoverflow.com/questions/21670967/how-to-compile-dts-linux-device-tree-source-files-to-dtb), changing line 1207
- amlogic,tx-delay-ns = <0x02>;
+ amlogic,tx-delay-ns = <0x04>;
and then converting it back to dtb.
In short, you have to add 2ns to the TX for it to work properly.
Before fixing it
iperf3 -c 192.168.0.1
Connecting to host 192.168.0.1, port 5201
[ 5] local 192.168.0.2 port 53012 connected to 192.168.0.1 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 5.68 MBytes 47.7 Mbits/sec 418 1.41 KBytes
[ 5] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes
[ 5] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes
[ 5] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes
[ 5] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 5] 5.00-6.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 5] 6.00-7.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 5] 7.00-8.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes
[ 5] 8.00-9.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 5] 9.00-10.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 5.68 MBytes 4.77 Mbits/sec 422 sender
[ 5] 0.00-10.00 sec 2.21 MBytes 1.85 Mbits/sec receiver
iperf Done.
After fixing it
iperf3 -c 192.168.0.1
Connecting to host 192.168.0.1, port 5201
[ 5] local 192.168.0.2 port 53526 connected to 192.168.0.1 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 114 MBytes 959 Mbits/sec 0 467 KBytes
[ 5] 1.00-2.00 sec 112 MBytes 943 Mbits/sec 0 486 KBytes
[ 5] 2.00-3.00 sec 111 MBytes 934 Mbits/sec 0 495 KBytes
[ 5] 3.00-4.00 sec 112 MBytes 943 Mbits/sec 0 444 KBytes
[ 5] 4.00-5.00 sec 111 MBytes 934 Mbits/sec 0 492 KBytes
[ 5] 5.00-6.00 sec 111 MBytes 933 Mbits/sec 0 486 KBytes
[ 5] 6.00-7.00 sec 112 MBytes 944 Mbits/sec 0 484 KBytes
[ 5] 7.00-8.00 sec 111 MBytes 933 Mbits/sec 0 484 KBytes
[ 5] 8.00-9.00 sec 112 MBytes 944 Mbits/sec 0 447 KBytes
[ 5] 9.00-10.00 sec 111 MBytes 933 Mbits/sec 0 467 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 1.09 GBytes 940 Mbits/sec 0 sender
[ 5] 0.00-10.00 sec 1.09 GBytes 938 Mbits/sec receiver
iperf Done.
I don't know if this is unique to my device or if all Beelink-Mini-MX-2G have this problem with telos.dtb.
I hope it helps.
@ophub, THANK YOU VERY MUCH for allowing us to continue using our Android TV boxes.
P.S.: I don't know if this was the right place to post the solution. I thought that more people can see it here. If it's not, please move it to the right place.
Translated with www.DeepL.com/Translator (free version)
The source code of dtb is in the kernel source code: https://github.com/unifreq/linux-5.15.y/tree/main/arch/arm64/boot/dts/amlogic
flymike shared the available meson-gxbb-vega-s95-telos.dtb and u-boot-s905.bin of the Beelink-Mini-MX-2G s905 box in Issues
Using 5.10.x kernel and meson-gxbb-vega-s95-telos.dtb, Gigabit ethernet and WiFi work
You can upload your modified dtb file, and I will make a backup so that you can replace the test with the same user as you.
thanks for sharing.
Hi, I will upload the dts if you want to compare it. meson-gxbb-vega-s95-telos_fix_MiniMX2GB16GB.dts.txt
I provide the data of my system in case it helps.
Armbian_22.02.0_Aml_s905_focal_5.10.101_2022.02.19.0130.img.gz
$uname -a
Linux armbian 5.10.102-flippy-70+ #202 SMP PREEMPT Wed Feb 23 19:47:27 CST 2022 aarch64 aarch64 aarch64 aarch64 GNU/Linux
P.S.: Sorry, I'm not an expert and I'm not fluent in English. In case I missed something.
Translated with www.DeepL.com/Translator (free version)
@atsdai Thank you for sharing
meson-gxbb-beelink-minimx-2g-16g.dtb.zip
This is compiled using your dts file, you can test whether it can be used. I have a warn when compiling, but it also compiles.
Instead of decompiling dtb, maybe you can make a copy of the standard source code and modify it. Did you just modify 1 place, changing 2 to 4?
This is compiled using your dts file, you can test whether it can be used. I have a warn when compiling, but it also compiles.
Ok, I'll try it tomorrow.
Instead of decompiling dtb, maybe you can make a copy of the standard source code and modify it. Did you just modify 1 place, changing 2 to 4?
Yes, 2 to 4.
I got the idea for the solution from this post https://lore.kernel.org/linux-arm-kernel/e21320b3-6e99-25a4-20d9-e8c5aa1aff03@gmail.com/T/
Specifically with this information https://patchwork.ozlabs.org/patch/1215313/
I don't know if it's only with my Mini MX board or if it happens with all of them. I don't know if @flymike has tried doing an iperf3 to make sure the transmission (TX) is correct. Apparently the network was working, but it would instantly drop out or its performance was very bad.
I repeat, I am not an expert in these matters and I am groping a bit. In this case the flute has sounded :D (I don't know if it has been translated with the same meaning xD).
Translated with www.DeepL.com/Translator (free version)
meson-gxbb-beelink-mini-mx.dts.zip
I haven't modified dtb before, and I learned how to create a new dtb under the guidance of flippy in the morning. If you only modify this place, you can create a separate dts file and modify only one line of code, so that other parts of the code will be updated with the upstream for a long time.
// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
/*
* meson-gxbb-beelink-mini-mx.dts
* Copyright (c) 2022 atsdai, unifreq, ophub
*/
/dts-v1/;
#include "meson-gxbb-vega-s95.dtsi"
/ {
compatible = "azw,mini-mx", "amlogic,meson-gxbb";
model = "Beelink Mini MX";
};
ðmac {
amlogic,tx-delay-ns = <4>;
};
I used the source code to change a dtb for you, and the test passed. I will ask flippy to check again to see if this dtb can be added to his kernel.
Can this device only be used on USB/TF, and can't be written to emmc?
Now this dtb has been added to the kernel source code of unifreq 5.4/5.10/5.15/5.16, you can use meson-gxbb-beelink-mini-mx.dtb in the future
738d19d
Thanks for sharing, I record it in the contributor list: https://github.com/ophub/amlogic-s9xxx-armbian/blob/main/CONTRIBUTOR.md
Can this device only be used on USB/TF, and can't be written to emmc?
I have never tried from emmc. I always use USB/TF.
I haven't tried WiFi or BT either. The use of the box is as a server. If I can I'll try it tomorrow too (at least the WiFi).
If you only modify this place, you can create a separate dts file and modify only one line of code, so that other parts of the code will be updated with the upstream for a long time.
Ok, I got it. Thanks!
I upload two images of the board.
WiFi works, at a not very high speed, but it works.
iperf3 -c 192.168.0.1
Connecting to host 192.168.0.1, port 5201
[ 5] local 192.168.0.2 port 24866 connected to 192.168.0.1 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 2.61 MBytes 21.8 Mbits/sec 0 59.4 KBytes
[ 5] 1.00-2.00 sec 2.24 MBytes 18.8 Mbits/sec 0 79.2 KBytes
[ 5] 2.00-3.00 sec 2.24 MBytes 18.8 Mbits/sec 0 73.5 KBytes
[ 5] 3.00-4.00 sec 1.86 MBytes 15.6 Mbits/sec 0 65.0 KBytes
[ 5] 4.00-5.00 sec 2.61 MBytes 21.9 Mbits/sec 0 76.4 KBytes
[ 5] 5.00-6.00 sec 1.86 MBytes 15.6 Mbits/sec 0 70.7 KBytes
[ 5] 6.00-7.00 sec 2.24 MBytes 18.8 Mbits/sec 0 62.2 KBytes
[ 5] 7.00-8.00 sec 1.86 MBytes 15.6 Mbits/sec 0 53.7 KBytes
[ 5] 8.00-9.00 sec 2.24 MBytes 18.8 Mbits/sec 0 62.2 KBytes
[ 5] 9.00-10.00 sec 2.24 MBytes 18.8 Mbits/sec 0 62.2 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 22.0 MBytes 18.4 Mbits/sec 0 sender
[ 5] 0.00-10.01 sec 21.1 MBytes 17.7 Mbits/sec receiver
iperf Done.
iperf3 -c 192.168.0.1 -R
Connecting to host 192.168.0.1, port 5201
Reverse mode, remote host 192.168.0.1 is sending
[ 5] local 192.168.0.2 port 24884 connected to 192.168.0.1 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 3.82 MBytes 32.0 Mbits/sec
[ 5] 1.00-2.00 sec 3.13 MBytes 26.3 Mbits/sec
[ 5] 2.00-3.00 sec 4.38 MBytes 36.8 Mbits/sec
[ 5] 3.00-4.00 sec 3.59 MBytes 30.1 Mbits/sec
[ 5] 4.00-5.00 sec 4.43 MBytes 37.2 Mbits/sec
[ 5] 5.00-6.00 sec 3.50 MBytes 29.3 Mbits/sec
[ 5] 6.00-7.00 sec 4.29 MBytes 36.0 Mbits/sec
[ 5] 7.00-8.00 sec 3.43 MBytes 28.8 Mbits/sec
[ 5] 8.00-9.00 sec 4.48 MBytes 37.6 Mbits/sec
[ 5] 9.00-10.00 sec 3.86 MBytes 32.3 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.30 sec 41.6 MBytes 33.9 Mbits/sec 0 sender
[ 5] 0.00-10.00 sec 38.9 MBytes 32.6 Mbits/sec receiver
iperf Done.
I'm trying to get bluetooth to work, because I can't make it visible to other devices, nor can I discover other devices.
armbian-config
enable bluetooth
The dtb fix amlogic,tx-delay-ns = <4> also works for Ugoos AM6 plus which also has RTL8211F phy. It makes the 1G wired connection stable (before the fix I usually ran the wired connection with 100Mbps to get stability).
(There have been a lot of discussions about the RTL8211F on the mailing lists over at patchwork.kernel.org, including the RX/TX delays, but I never saw anything really resolving it for my Ugoos, but this fix apparently did.)
Ugoos AM6 plus which dtb did you use?
meson-g12b-ugoos-am6.dtb?
Yes, from your 5.17.2 kernel build (but I actually run a Manjaro 5.14 kernel, since I mainly run Manjaro on my Ugoos)
ok. Test if 5.10/5.15 is stable after modification
I have tested your 5.10.111 (with the 5.17.2 dtb) and it is stable (I can only test up to 200Mbit download; no errors or resets in dmesg). I cannot boot 5.15 from my SD card (it is a common problem I have with newer kernels above, say 5.14, possibly due to my chain loading using (hexdump's) u-boot.ext).
Ok, thanks for sharing the test results
The dtb fix
amlogic,tx-delay-ns = <4>also works for Ugoos AM6 plus which also has RTL8211F phy. It makes the 1G wired connection stable (before the fix I usually ran the wired connection with 100Mbps to get stability).(There have been a lot of discussions about the RTL8211F on the mailing lists over at patchwork.kernel.org, including the RX/TX delays, but I never saw anything really resolving it for my Ugoos, but this fix apparently did.)
I am very glad you found my contribution useful. :)
@tri-pole
Is your device s905x3?
Please submit your dmesg results and ifconfig results
unifreq recommends referring to this document to adjust parameters:
https://github.com/unifreq/linux-5.15.y/blob/main/Documentation/devicetree/bindings/net/amlogic%2Cmeson-dwmac.yaml
ðmac {
phy-mode = "rgmii";
/delete-property/ rx-internal-delay-ps;
amlogic,tx-delay-ns = <2>; /* 0,2,4,6 */
};
or
ðmac {
phy-mode = "rgmii-txid";
/delete-property/ amlogic,tx-delay-ns;
rx-internal-delay-ps = <800>;
/* if compatible = amlogic,meson-g12a-dwmac: 0 to 3000, step 200 */
/* else 0 or 2000 */
};
Sorry, I didn't see your latest post above.
I'm running a different distro now with kernel 5.14.10-1-MANJARO-ARM and I don't have the ifconfig command but I use the meson-g12b-ugoos-am6.dtb from from your 5.17.2 kernel build with the amlogic,tx-delay-ns = <4> fix and the 1GB connection is stable.
Here is some info about my AM6 plus box with s922 SoC:
# dmesg | head -n600 | egrep -i "(AM6|Amlogic|eth|dwmac|1Gb)"
[ 0.000000] Machine model: Ugoos AM6
[ 0.000000] psci: probing for conduit method from DT.
[ 2.890044] soc soc0: Amlogic Meson G12B (S922X) Revision 29:b (40:2) Detected
[ 4.808360] meson8b-dwmac ff3f0000.ethernet: IRQ eth_wake_irq not found
[ 4.814384] meson8b-dwmac ff3f0000.ethernet: IRQ eth_lpi not found
[ 4.820586] meson8b-dwmac ff3f0000.ethernet: PTP uses main clock
[ 4.826912] meson8b-dwmac ff3f0000.ethernet: User ID: 0x11, Synopsys ID: 0x37
[ 4.833527] meson8b-dwmac ff3f0000.ethernet: DWMAC1000
[ 4.838712] meson8b-dwmac ff3f0000.ethernet: DMA HW capability register supported
[ 4.846121] meson8b-dwmac ff3f0000.ethernet: RX Checksum Offload Engine supported
[ 4.853535] meson8b-dwmac ff3f0000.ethernet: COE Type 2
[ 4.858713] meson8b-dwmac ff3f0000.ethernet: TX Checksum insertion supported
[ 4.865699] meson8b-dwmac ff3f0000.ethernet: Wake-Up On Lan supported
[ 4.872107] meson8b-dwmac ff3f0000.ethernet: Normal descriptors
[ 4.877948] meson8b-dwmac ff3f0000.ethernet: Ring mode enabled
[ 4.883722] meson8b-dwmac ff3f0000.ethernet: Enable RX Mitigation via HW Watchdog Timer
[ 11.811168] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 13.613898] meson8b-dwmac ff3f0000.ethernet eth0: PHY [0.0:00] driver [RTL8211F Gigabit Ethernet] (irq=37)
[ 13.619359] meson8b-dwmac ff3f0000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
[ 13.633879] meson8b-dwmac ff3f0000.ethernet eth0: No Safety Features support found
[ 13.635790] meson8b-dwmac ff3f0000.ethernet eth0: PTP not supported by HW
[ 13.642699] meson8b-dwmac ff3f0000.ethernet eth0: configuring for phy/rgmii link mode
[ 16.321812] meson8b-dwmac ff3f0000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[ 16.324828] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
# ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Link partner advertised pause frame use: Symmetric Receive-only
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Auto-negotiation: on
master-slave cfg: preferred slave
master-slave status: master
Port: Twisted Pair
PHYAD: 0
Transceiver: external
MDI-X: Unknown
When I get time I will try your recommendation from unifreq and add also some rx-internal-delay-ps (but right now it does not seem to be needed).
ok