Jump to content

chrismade

Members
  • Posts

    9
  • Joined

  • Last visited

Posts posted by chrismade

  1. 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)

  2. 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

  3. 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) ? 

  4. 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

  5. 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)??

     

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines