So any idea @7Ji?
When the issues are solved we can merge the PR.
The stmmac driver is loaded the same on my S905X3 box and other users’ S905X4 boxes, but there seems some differences on how the driver actually work on them. Maybe S905X4 has different MAC part from S905X3?
Now I’m even not confident on the PR as a whole, maybe it even only works on my box and not on any other boxes? I can’t quite get this solved as I don’t have a S905X4 with JL2101 nor other S905X3 boxes besides my HK1 BOX with JL2101.
You will need to make debug images with the other users to solve the driver issues, that’s how we solve such issues.
These “cheap chinese” boxes come same like all the other X… boxes what we preach again and again to not buy such hardware…
Maybe the Generic PHY driver does not play too well with S905X4, can you try the official JL2101 driver from JLSemi?
Follow the instructions in my last comment in the PR (this link should point you to it), you should be able to unbind the PHY from the Generic PHY driver and bind it to the precompiled official driver.
I tried that now too, and had exactly same error as emveepee:
pull/13#issuecomment-1194021920
[ 308.384279@2]- net eth0: failed to get the device driver module
[ 308.384285@2]- eth0: Could not attach to PHY
[ 308.384288@2]- stmmac_open: Cannot attach to PHY (error: -5)
[ 525.671799@0]- net eth0: failed to get the device driver module
[ 525.671806@0]- eth0: Could not attach to PHY
[ 525.671808@0]- stmmac_open: Cannot attach to PHY (error: -5)
CoreELEC:~/backup # lsmod | grep jl
jl2xx1 20480 -1
CoreELEC:~/backup # ls -l /sys/bus/mdio_bus/devices/*/driver
lrwxrwxrwx 1 root root 0 Jul 25 13:36 /sys/bus/mdio_bus/devices/stmmac-0:00/driver -> ../../../../../../bus/mdio_bus/drivers/JL2101 Gigabit Ethernet
lrwxrwxrwx 1 root root 0 Jul 25 13:36 /sys/bus/mdio_bus/devices/stmmac-0:07/driver -> ../../../../../../bus/mdio_bus/drivers/JL2101 Gigabit Ethernet
CoreELEC:~/backup # ifconfig -a
eth0 Link encap:Ethernet HWaddr 90:0E:B3:44:29:81
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:225 errors:0 dropped:0 overruns:0 frame:0
TX packets:78 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:44138 (43.1 KiB) TX bytes:29350 (28.6 KiB)
Interrupt:16
lo Link encap:Local Loopback
---8<---
CoreELEC:~/backup # lsmod | grep jl
jl2xx1 20480 -1
Afer loading driver (3. Inset the module into the kernel: insmod jl2xx1.ko), the connection was still unstable, (cannot ssh to box on LAN IP), so i disabled LAN in CoreElec GUI System Settings to restart it, but then it could not be re-enabled, this causes error code shown in dmesg.
I modified the official JL2101 driver once again and now it can be loaded without any error on boot or during userspace. Can you try this test image to check if the network now works on S905X4?
https://drive.google.com/drive/folders/1vgXiphp1fPJ7A6lvTePSKw7WTnRtpPYi?usp=sharing
There’s both the update tarball and full generic image, both should work. If you can test both that’ll be much appreciated
@7Ji it does load the JL2101 driver instead of GENERIC PHY but it still initializes with the bogus MAC and doesn’t work
The MAC address is provided by another part of the hardware in SoC itself and my modifications didn’t touch the MAC-related stuff other than that stmmac delay. The MAC address on my HK1 RBOX X4 with a Realtek PHY is also faulty (all 00 for the last 4 hexes) but it works, I guess it’s a common issue for the box/SoC. It can be worked around with some ifconfig commands.
As for your problem about how to make it work other than the MAC part, I don’t have any more ideas 
@Kill_Bill I’m more curious if this will improve the performance and make the wired ethernet at least usable when the Generic PHY driver can drive it but is not usable. Can you also try the test image? If this works for you then there’s at least some of the S905X4 boxes that can benefit from the official driver.
1 Like
My MAC shows 4 zeroes but even 02:0E:00:00:00:00 the 0E is wrong. I still figure we need to wait for kernel 5.4
Mine X4 MAC is 02:21:00:00:00:00 under CE and 02:ad:… under Android. This does not stop the network from working, though.
I tried new jl2xx1.ko driver now on same image installation as before (portisch tar file update to 19.5 from 24 jul), and now i can down eth0 and up again without error.
(that was CoreELEC (community): 19.5-Matrix_devel_20220724143615 (Amlogic-ng.arm))
But connection is still very unstable. I cannot copy file to samba share on box, and often ssh to box fails, same as before. So there is also another problem how the driver has to initialize the hardware or something.
Will try the whole image later.
I flashed image (CoreELEC-Amlogic-ng.arm-19.5-Matrix_devel_20220728001259-Generic.img) , but there CoreELEC configuration / settings Addon is not working “not ready”, but is needed to setup ssh and WLAN network. Since LAN is still not working properly, it cannot be installed, doesn’t find online repo.
edit:
Well, i restarted box without LAN cable attached, and now the settings Addon worked, and i could make initital setup config.
But LAN connection 1Gb is still unstable, and for example as i tried to copy some screenshots from smb share on box to notebook, the connection got lost.
I really got no idea how to make JL2101 work on S905X4 now… Everything expected to work all however broken on these boxes…
But I have a method to get rid of the boogus MAC address, put the following content as a service file under /storage/.config/system.d, e.g. /storage/.config/system.d/macsetup.service
[Unit]
Description=Setup correct MAC address
After=sys-subsystem-net-devices-eth0.device
Before=network-base.service
[Service]
Type=oneshot
ExecStart=/usr/sbin/ifconfig eth0 hw ether write:your:mac:address:at:here
[Install]
WantedBy=network.target
And enable it: systemctl enable macsetup.service
Then reboot, the MAC address should be whatever you define it. Tested to work on my HK1 RBOX X4 with Realtek PHY
This was not a problem on my box X96_X4, which recognized the correct MAC address.
And also mayby PHY jl2xx1 driver is not the problem, but the NIC driver,
because changing PHY from generic to jl2xx1 did not improve connection quality.
I uploaded a coreELEC log, which was when the LAN did work, but in unstable state.
http://ix.io/45Uh
In the logfile, there are two PHY listed, one should be the Amlogic internal 10/100Mb, the other 1Gb, i suppose.
Is it possible, that the wrong one was selected, because even connection showed 1Gb LAN, it was verry slow, and unstable, or is it possible to shut down the unused PHY, so that it cannot interfere signal quality?
Aug 06 16:43:07.776052 CoreELEC kernel: mtdoops: mtd device (mtddev=name/number) must be supplied
Aug 06 16:43:07.776147 CoreELEC kernel: libphy: Fixed MDIO Bus: probed
Aug 06 16:43:07.776226 CoreELEC kernel: auto_cali_idx 0
Aug 06 16:43:07.776781 CoreELEC kernel: meson6-dwmac fdc00000.ethernet: no reset control found
Aug 06 16:43:07.776897 CoreELEC kernel: stmmac - user ID: 0x11, Synopsys ID: 0x37
Aug 06 16:43:07.777024 CoreELEC kernel: Ring mode enabled
Aug 06 16:43:07.777130 CoreELEC kernel: DMA HW capability register supported
Aug 06 16:43:07.777186 CoreELEC kernel: Normal descriptors
Aug 06 16:43:07.777239 CoreELEC kernel: RX Checksum Offload Engine supported
Aug 06 16:43:07.777293 CoreELEC kernel: COE Type 2
Aug 06 16:43:07.777346 CoreELEC kernel: TX Checksum insertion supported
Aug 06 16:43:07.777426 CoreELEC kernel: Wake-Up On Lan supported
Aug 06 16:43:07.777476 CoreELEC kernel: Enable RX Mitigation via HW Watchdog Timer
Aug 06 16:43:07.777527 CoreELEC kernel: libphy: stmmac: probed
Aug 06 16:43:07.777578 CoreELEC kernel: eth%d: PHY ID 937c4032 at 0 IRQ POLL (stmmac-0:00) active
Aug 06 16:43:07.777632 CoreELEC kernel: eth%d: PHY ID 937c4032 at 7 IRQ POLL (stmmac-0:07)
When i do this command on my linux notebook, i get only one result, not two (also connectet with Gb LAN), so you only need one at a time:
[root@.... /]# ls -l /sys/bus/mdio_bus/devices/*/driver
lrwxrwxrwx. 1 root root 0 28. Jul 19:53 /sys/bus/mdio_bus/devices/r8169-0-200:00/driver -> '../../../../../../../bus/mdio_bus/drivers/Generic FE-GE Realtek PHY'
[root@.... /]#
What you are suggesting is what 7Jl’s last patch was trying instead of connecting to GENERIC PHY it was connecting to JL2101 If you have the earlier test build if you follow the steps on github you can try both but it didn’t work for me.
I don’t think that will help, but if you want to disable the internal PHY:
Find which PHY is external, and which is internal
CoreELEC:~ # dmesg | grep eth%d
[ 0.747639@2]- eth%d: device MAC address 02:00:00:01:22:01
[ 0.889107@3]- eth%d: PHY ID 937c4032 at 0 IRQ POLL (stmmac-0:00) active
[ 0.889111@3]- eth%d: PHY ID 937c4032 at 1 IRQ POLL (stmmac-0:01)
In this case, external PHY is stmmac-0:00 (active), internal PHY is stmmac-0:01, you can find something interesting here: the internal PHY also has the same 937c4032 id (PHY id of JL2101) as external, this may be caused by some issue in the stmmac driver, but I don’t think this’ll break the network stack as it is not active at all. Note that usually only stmmac-0:00 is guaranteed, the other could has other name like stmmac-0:07
Find the driver each PHY uses
CoreELEC:~ # ls -l /sys/bus/mdio_bus/devices/*/driver
lrwxrwxrwx 1 root root 0 Jul 29 03:23 /sys/bus/mdio_bus/devices/stmmac-0:00/driver -> ../../../../../../bus/mdio_bus/drivers/JL2101 Gigabit Ethernet
lrwxrwxrwx 1 root root 0 Jul 29 03:23 /sys/bus/mdio_bus/devices/stmmac-0:01/driver -> ../../../../../../bus/mdio_bus/drivers/JL2101 Gigabit Ethernet
In this case the internal PHY is also assigned to JL2101 driver, due to the stmmac driver issue I mentioned earlier
Unbind the internal PHY from the driver
echo 'stmmac-0:01' > /sys/bus/mdio_bus/drivers/JL2101\ Gigabit\ Ethernet/unbind
Now the internal PHY should be completely disabled on the software layer as there’s no driver assigned to it (it can’t be shut down as it is part of the S905X4 SoC, it will be powered as long as the SoC is powered)
Note you can’t bind it to the internal driver, since the PHY is disabled when there’s external PHY
CoreELEC:~ # echo 'stmmac-0:01' > /sys/bus/mdio_bus/drivers/amlogic\ internal\ phy/bind
sh: echo: write error: No such device
And… nothing really changed, the external PHY is still driven by the same driver and the internal PHY is still not active
I found the address of S905X4 dtb’s ethernet node and the first reg value of the node is different while these two values are always same for other aml dtbs. Maybe this is faulty and cause some low level operations to fail? Can you try if the network improves with the following dtb?
sc2_s905x4_4g_1gbit_address_fix.dtb.gz (21.3 KB)
The dtb works on my HK1 Rbox X4 with a Realtek PHY so it at least does not break more things
I tried to unbind stmmac-0:07, and then up eth0 again, but did not help to get better results.
It gets then the generic driver loaded.
Anyhow, this is a screenshot from android, how it looks there:
edit: will try with other dtb next.
You don’t need to do the driver binding, just replace your dtb and it should work