chrismade

thanks @usual userfor looking this up - now we even have a version number - IMHO we can wait - anyone impacted by this issue needing an urgent fix can modify the DT file following the posted instructions above

** 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"; pinctrl-0 = <&pinctrl_microsom_enet_ar8035>; - phy-handle = <&phy>; phy-mode = "rgmii-id"; phy-reset-duration = <2>; phy-reset-gpios = <&gpio4 15 GPIO_ACTIVE_LOW>; @@ -63,10 +62,15 @@ #address-cells = <1>; #size-cells = <0>; - phy: ethernet-phy@0 { + ethernet-phy@0 { reg = <0>; qca,clk-out-frequency = <125000000>; }; + + ethernet-phy@4 { + reg = <4>; + qca,clk-out-frequency = <125000000>; + }; }; }; as you can see ... changes are applied to include-file "imx6qdl-sr-som.dtsi" in directory "arch/arm/boot/dts/" getting the device-tree binary requires a step in between because the device-tree source files make use of "#include" - a directive which the device tree compiler does NOT understand, so the gcc preprocessor must help here cpp -nostdinc -I include -I arch -undef -x assembler-with-cpp arch/arm/boot/dts/imx6q-cubox-i.dts imx6q-cubox-i.dts.preprocessed then you can start "dtc" next dtc -I dts -O dtb -p 0x1000 imx6q-cubox-i.dts.preprocessed -o imx6q-cubox-i-new.dtb the fixed device-tree-binary is now in file " imx6q-cubox-i-new.dtb" which need to replace "imx6q-cubox-i.dtb" in /boot/dtb (again - consider rename the orgininal file instead of delete or overwrite)

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:~$ next... read device-tree-binary (as non-root) from /boot/dtb/ and write source back into current directory: cubox-i:~$ dtc -I dtb -O dts -o imx6q-cubox-i.dts /boot/dtb/imx6q-cubox-i.dtb ignore warning: imx6q-cubox-i.dts: Warning (unique_unit_address): /soc/bus@2000000/iomuxc-gpr@20e0000: duplicate unit-address (also used in node /soc/bus@2000000/pinctrl@20e0000) cubox-i:~$ next... open in editor of your choice and find this sequence (should appear approx line 1250 ): ethernet@2188000 { compatible = "fsl,imx6q-fec"; reg = < 0x2188000 0x4000 >; interrupt-names = "int0\0pps"; interrupts = < 0x00 0x76 0x04 0x00 0x77 0x04 >; clocks = < 0x02 0x75 0x02 0x75 0x02 0xbe >; clock-names = "ipg\0ahb\0ptp"; fsl,stop-mode = < 0x01 0x34 0x1b >; status = "okay"; pinctrl-names = "default"; pinctrl-0 = < 0x2e >; phy-handle = < 0x2f >; delete the last line "phy-handle = < 0x2f >;" a few lines below you will find this block ethernet-phy@0 { reg = < 0x00 >; qca,clk-out-frequency = < 0x7735940 >; phandle = < 0x2f >; }; again... delete line "phandle = < 0x2f >;" next dublicate this block ethernet-phy@0 { reg = < 0x00 >; qca,clk-out-frequency = < 0x7735940 >; }; and modify the first two lines in the 2nd block to ethernet-phy@4 { reg = < 0x04 >; qca,clk-out-frequency = < 0x7735940 >; }; both blocks then look like ethernet-phy@0 { reg = < 0x00 >; qca,clk-out-frequency = < 0x7735940 >; }; ethernet-phy@4 { reg = < 0x04 >; qca,clk-out-frequency = < 0x7735940 >; }; safe the file and compile to binary cubox-i:~$ dtc -I dts -O dtb -o imx6q-cubox-i.dtb imx6q-cubox-i.dts unfortunately you will (again) see lots of warnings (really ... a lot): imx6q-cubox-i.dtb: Warning (unique_unit_address): /soc/bus@2000000/iomuxc-gpr@20e0000: duplicate unit-address (also used in node /soc/bus@2000000/pinctrl@20e0000) imx6q-cubox-i.dtb: Warning (clocks_property): /ldb:clocks: cell 0 is not a phandle reference imx6q-cubox-i.dtb: Warning (clocks_property): /ldb:clocks: cell 2 is not a phandle reference imx6q-cubox-i.dtb: Warning (clocks_property): /ldb:clocks: cell 4 is not a phandle reference ignore warning - I usually take warning always very seriously but not in this case now the fixed device tree is in file imx6q-cubox-i.dtb in your current directory before you copy (now as root) into /boot/dtb you may want to _rename_ the old file - so you could mount the SDcard of your cubox on another computer and restore this original file if required with this modified (self fixed) device tree newer kernels should have ethernet regardless if your cubox has PHY on addr #0 or #4 Note: device-tree-files can be used on various kernels from the same generation - between generations there might be breaking changes

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 old driver until 5.7.x - so all these users won't experience this issue usually (however, remaining on older kernels have risks, too) Regarding the issue it looks like a period of production - neither at the beginning nor at the end - PHY got a different addr (04 instead of 00) and the new driver from 5.8.x onwards only expects addr 00 - and hence does not work if PHY is on addr 04 I wonder if there is a serial number or similar - I haven't found anything like this yet - if there is really none - maybe the MAC address printed on the bottom helps is to identify which cuboxes have the PHY on addr 04 ? My only cubox having this addr on 04 instead of 00 has MAC = D0 63 B4 - 00 77 BB @Armbian_User- or anyone else - can you pls check if your affected systems are near that range (the last 3 bytes matter) ?

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 still ok. From my collection 2 out of 3 are working ok also with 5.8.x kernel and higher This one has issues (stopped working after upgrade to 5.8.x) SolidRun i4P TV-300-D while these are still working SolidRun 4x4 300-D SolidRun i2EXW 300-D if the (last 3 bytes from) MAC address is just incrementing during production then the one box having issues is in between the two which are working - The two which are working have WiFi and the one which has issues does not - but that does not fit to the post above from "Armbian User" who reported issues on a WiFi version There might be one more thing find /sys -name phy_id /sys/devices/platform/soc/2100000.bus/2188000.ethernet/mdio_bus/2188000.ethernet-1/2188000.ethernet-1:00/phy_id reported on the systems which work (on 5.8.x and beyond) while my system which breaks reports /sys/devices/soc0/soc/2100000.bus/2188000.ethernet/mdio_bus/2188000.ethernet-1/2188000.ethernet-1:04/phy_id which has two differences: after /devices/ we see /soc0/ instead of /platform/ and further in the path /2188000.ethernet-1:04/ instead of /2188000.ethernet-1:00/ device tree seems to be the same for all there are small differences - and these seem to matter - if someone still reads this post ... and wants to contribute ... and has a system which broke from upgrading 5.7.x > 5.8.x *kindly check on your system* and post results here - for find /sys -name phy_id which is always an important part of troubleshooting to sort apart systems which still work and those which break - and to find reliable criteria which belongs to which group

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 loading via modprobe results in an error message now comparing the two packages shows a difference in file "modules.alias" /lib/modules/5.7.15-imx6 alias mdio:00000000010011011101000001000001 at803x alias mdio:000000000100110111010000011?0010 at803x alias mdio:000000000100110111010000011?0100 at803x alias mdio:000000000100110111010000011?0110 at803x (working) to /lib/modules/5.8.5-imx6 alias mdio:00000000010011011101000001000001 at803x alias mdio:00000000010011011101000001110010 at803x alias mdio:00000000010011011101000000100011 at803x alias mdio:00000000010011011101000001110100 at803x alias mdio:000000000100110111010000011?0110 at803x (not working on *some* cubox) not only the number of lines differs, also check the question marks in the working config! It seems that the driver checks these HW keys in order to ensure HW is really there - and if these keys does not match driver does not load and hence eth0 is not working. Depending which exact type of cubox you have ... it will load - or not - which might explain why it works on Igor's cubox while other have issues. Unfortunately just editing the modules-alias won't do the fix, we also need to generate a "modules.alias.bin" after the change - does anyone know how to do this (so I can resume testing)??