chrismade

** update - received this feedback today: The fix has been submitted, Sh___ G__* applied it, it should eventually end up in mainline soon and backported to stable kernels. *) name modified due protect privacy Thats good news - keep your cubox(es) updated

alternatively ... and more elegant ... you can build that device-tree from kernel sources - e.g. download a 5.x.y kernel from kernel.org (I tested if with linux-5.10.6 ), unpack it and enter the source directory ( cd linux-5.10.6 in my case ) This is the diff which I got from the kernel developer diff --git a/arch/arm/boot/dts/imx6qdl-sr-som.dtsi b/arch/arm/boot/dts/imx6qdl-sr-som.dtsi index b06577808ff4..3db08363d3fb 100644 --- a/arch/arm/boot/dts/imx6qdl-sr-som.dtsi +++ b/arch/arm/boot/dts/imx6qdl-sr-som.dtsi @@ -53,7 +53,6 @@ &fec { pinctrl-names = "default

I haven't heard back from kernel developers if/when we could expect a fix - I assume they are currently busy fixing other issues - if you are impacted or afraid to update your cubox because you might be impacted ... here is how you can fix it yourself (modify the required device-tree file). Luckily the tool "dtc" should be in our armbian image already and this tool works bi-directional, can make binaries out of source - and vice versa! Here is how check if "dtc" = device-tree-compiler available - and if it is the required version: cubox-i:~$ dtc -v Version: DTC 1.4.7 cubox-i:~$

I just tested successfully a patch in the device tree from one of the kernel developers which fixes that problem for all cuboxes which have PHY on addr 0x04 instead of 0x00 for newer kernels - stay tuned..

There is another observation ... the ones which started early on Armbian Debian Buster for cubox don't get any kernel updates - which might be another reason why the number of Armbian users reporting this issue is low - early Armbian Debian buster images receive updates on other packages and will be updated to 10.7 after "apt update && apt upgrade" but kernel remains in 5.3.1 (forever or only when updated manually) - the HW effect reported in this thread, that the PHY is usually on addr 00 while it seems on _some_ hardware it is on addr 04 was either ignored or somehow handled by the o

Thanks @Armbian_User it seems we are coming closer to find reliable criteria which systems are affected - I see the same pattern on my cuboxes anyone else ? btw: the message find: ‘/sys/module/at803x/drivers’: Input/output error as well as the MM error / trace in dmesg is expected - at least seems not related to this issue

I'm currently in contact with maintainers of this driver "at803x" - the first assumption that just a single line regarding the device ID (see my post above ... modules.aliases, which btw is created by depmod) was missing in the driver source was (unfortunately) wrong. The driver for this device has been widely reworked from 5.7.x (rather simple, only recognizing AT8030 and AT8035) to 5.8.x (now rather complex and supporting much more devices from that family beyond 8030/8035) - Another finding was that NOT ALL cuboxes are impacted - already reported by Igor that his regression box is st

this break happens when you update from linux-dtb-current-imx6_20.08_armhf.deb 29-Aug-2020 20:02 linux-image-current-imx6_20.08_armhf.deb 29-Aug-2020 20:03 (still working, linux-5.7.15-imx6) to linux-dtb-current-imx6_20.08.1_armhf.deb 30-Aug-2020 20:34 linux-image-current-imx6_20.08.1_armhf.deb 30-Aug-2020 20:34 (breaking on *some* cubox-i, linux-5.8.5-imx6 ) the obvious reason for breaking is that kernel driver ./kernel/drivers/net/phy/at803x.ko is no longer loading - driver exists, but manual l