Ethernet not working on SOPINE module

[siffland]

Armbianmonitor:

http://ix.io/1yOX

I just upgraded (using a fresh image with the 5.69 image) one of my SOPINE A64 modules from Armbian Xenial - legacy kernel 3.10.y to Armbian Bionic - mainline kernel 4.19.y.  The onboard ethernet will no longer work.  The sopine module is connected to a clusterboard instead of a sopine baseboard, but the NIC is on the module so it should not make a difference. 

 

On Xenial 3.10.y kernel the driver loaded for the NIC is the sunxi_geth driver, on bionic 4.19.y kernel it is the st_mac100 driver. 

 

Here is the output of the lshw for 4.19.y

  *-network:0
       description: Ethernet interface
       physical id: 6
       logical name: eth0
       serial: 02:ba:9b:53:82:7a
       size: 1Gbit/s
       capacity: 1Gbit/s
       capabilities: ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=st_mac100 driverversion=Jan_2016 duplex=full link=yes multicast=yes port=MII speed=1Gbit/s

 

I have a USB dongle plugged in and that works to get the machine online for testing.  In the same clusterboard i have more modules still on the old image and they have no issues with networking.  Let me know what other information i can supply.

 

Thanks,

Sean

[siffland]

I also tried the debian strech 5.69 image and had the same results.  Is there anything else i can try?

 

Thanks,

Sean

[Igor]

12 hours ago, siffland said:

debian strech

Debian based images have the same kernel as Bionic. It's our kernel.
 

12 hours ago, siffland said:

Is there anything else i can try?

 

- build images on your own. U-boot has been changed. Could have effect

- build DEV branch instead of NEXT (contain kernel 4.20.y)

[PigLover]

This appears to be the same issue that was fixed for the Legacy kernel, but not carried forward.

 

Two fixed are possible - add a "tx-delay" in the DTB or a fix some constants in the Realtek driver.  I've confirmed that the DTB fix corrects the issue.

 

Add

    allwinner,tx-delay-ps = <500>;

 

to the ethernet device and it works.  Continues to work when soPine is plugged into the baseboard instead of the clusterboard.

 

Detail on the more complex fix here: https://patchwork.ozlabs.org/patch/873752/

 

                ethernet@1c30000 {
                        compatible = "allwinner,sun50i-a64-emac";
                        syscon = <0x2d>;
                        reg = <0x1c30000 0x10000>;
                        interrupts = <0x0 0x52 0x4>;
                        interrupt-names = "macirq";
                        resets = <0x2 0xd>;
                        reset-names = "stmmaceth";
                        clocks = <0x2 0x24>;
                        clock-names = "stmmaceth";
                        status = "okay";
                        pinctrl-names = "default";
                        pinctrl-0 = <0x2e>;
                        phy-mode = "rgmii";
                        phy-handle = <0x2f>;
                        phy-supply = <0x30>;
                        phandle = <0x6f>;
                        allwinner,tx-delay-ps = <500>;

                        mdio {
                                compatible = "snps,dwmac-mdio";
                                #address-cells = <0x1>;
                                #size-cells = <0x0>;
                                phandle = <0x70>;

                                ethernet-phy@1 {
                                        compatible = "ethernet-phy-ieee802.3-c22";
                                        reg = <0x1>;
                                        phandle = <0x2f>;
                                };
                        };
                };

 

[PigLover]

On the above - forgot to mention - the dtb file that needs to be edited is "sun50i-a64-sopine-baseboard.dtb"

[siffland]

Following this post on the pine pages with the same issue:

https://forum.pine64.org/archive/index.php?thread-5581-3.html

 

and using this u-boot (referenced from the above link) fixed the issue for me.

https://github.com/janwillies/u-boot/releases/tag/v2019.01-cb-1

 

So which method is the best fix for this.  I would think your driver method is, but this u-boot modification also worked.

 

Thanks,

Sean

[siffland]

Before i tried the u-boot in the fix above (form the pine64 forums) i did compile mainline u-boot and that did not work, i also compile mainline kernel 5.0-rc3 and that didnt fix the issue (although it runs fine) .  Just wanted to add that.

[langerma]

so in the official images there is no fix applied for this issue?

[BryanS]

@langerma

I just tried the latest release on the clusterboard, and it appears there are no fixes applied yet.

 

I was able to get the baseboard to boot with Ethernet using the latest release. I'm not really up on re-compiling kernels yet, but I'm more than happy to provide any information requested to get this resolved.

[langerma]

@BryanS thx for the info. i tried recompiling the whole thing a few times. booting worked but still without ethernet. i  used an older version of armbian, which was mentioned in the clusterboard forum.

 

seems like, that not that many persons are using the clusterboards :-(

[BryanS]

5 hours ago, langerma said:

seems like, that not that many persons are using the clusterboards :-(

 

That does seem to be the case. Hopefully this will change in the future - I really want to use this thing as a hardware docker-like device. If there's any information I can provide, please let me know.

[siffland]

I use my cluserboard as a docker swarm, works pretty nice.  See my post above about the solution i found with the custom u-boot version.  I just burn armbian to a micro sdcard and then dd the custom u-boot to the card and everything works fine.  

 

The second link from the jan willies github explains how to do this and doing a diff from his github shows the changes he has to make to u-boot.  I dont know if this can be submitted upstream to u-boot, i wish i knew a lot more about u-boot.

 

So this is a u-boot problem.

 

on a totally off topic note, the clusterboard and sopine modules are better performing than the raspberry pi modules and any backplane board i have found for them and way cheaper (the modules are about the same price but $99 for the backplane with Gb ethernet is a great deal and it is matx form factor so you can actually mount it in a case).

 

Thanks,

Sean

[Igor]

@siffland @BryanS @langerma @PigLover

Updated u-boot to latest. I hope I manage to transfer all what is needed. Don't have this hardware, pleas someone test if changes are O.K. after this

https://github.com/armbian/build/commit/c474e35fe1fc795154baf88dec36cc01c6a5b567

[BryanS]

I'm not sure how to incorporate the new u-boot, but if I can figure it out I will test it.

[Igor]

29 minutes ago, BryanS said:

I'm not sure how to incorporate the new u-boot, but if I can figure it out I will test it.

Download this image https://dl.armbian.com/pine64so/archive/Armbian_5.82_Pine64so_Ubuntu_bionic_next_4.19.36.7z and try.

[langerma]

is it possible to just upgrade my image by apt upgrade? (defreeze kernel pkgs beforehand)

[Igor]

8 hours ago, langerma said:

is it possible to just upgrade my image by apt upgrade? (defreeze kernel pkgs beforehand)

When someone will confirm that its working, I will push update to the repository. Then, apt upgrade will make a difference. And manual u-boot update (from nand-sata-install menu) when important change is there.

[langerma]

okay...as i wanted to reinstall the boards i am going to test it this weekend

 

[siffland]

I have had this image running on one of my sopine boards (in my clusterboard) for about 18 hours.  I have done apt upgrades and rebooted several times and so far i have not had any networking issues.  

 

$ cat /etc/armbian-release
# PLEASE DO NOT EDIT THIS FILE
BOARD=pine64so
BOARD_NAME="SoPine A64"
BOARDFAMILY=sun50iw1
VERSION=5.82
LINUXFAMILY=sunxi64
BRANCH=next
ARCH=arm64
IMAGE_TYPE=stable
BOARD_TYPE=conf
INITRD_ARCH=arm64
KERNEL_IMAGE_TYPE=Image

 

Thanks,

Sean

[langerma]

is this a sopine on clusterboard or baseboard?

[siffland]

sopine on a clusterboard.

[AZClusterboard]

I haven't been given a lot of clear instructions about how to contribute as a board maintainer but the most recent regular builds are working and I got nightly builds up if this problem arises in the future. 

[Igor]

32 minutes ago, AZClusterboard said:

I haven't been given a lot of clear instructions about how to contribute as a board maintainer but the most recent regular builds are working and I got nightly builds up if this problem arises in the future. 

Keeping important information on the download pages as closer to reality as possible.

Reality: I did update images, but apt update and upgrade will not solve this problem until kernel update is pushed out. I hope this will happen once next week. Several other boards has to be checked and few urgent bugs fixed. Now is it worth to put this notice out for two weeks?

[AZClusterboard]

1 hour ago, Igor said:

Now is it worth to put this notice out for two weeks?

I'm not sure what you mean by this.  As far as wordpress goes, I did add links for the nightly builds.

[Igor]

12 minutes ago, AZClusterboard said:

I'm not sure what you mean by this. 

By adding a line with remarks or a link to this post (I just added)

 

14 minutes ago, AZClusterboard said:

As far as wordpress goes, I did add links for the nightly builds.

Good!

[langerma]

so reboots would work now on clusterboards if i update?

[ichibrosan]

I am finding it disappointing that after spending real money for the cluster, there is little or none

clear and straightforward information about reaching a botton line with this hardware. I have downloaded 

what appears to be good images and burned them to microSD and placed the module in the clusterboard

and powered it up. After waiting some minutes, there is no evidence at the router that any DHCP addresses

were allocated. I guess I assumed that there was a blessed configuration for us to start from and that each

of us wouldn't have to have a nearly base-metal experience just getting a basic linux running and an ssh

session up. I don't know whether to pack this kit back up and send it back or what.

[Igor]

On 6/12/2020 at 7:13 AM, ichibrosan said:

after spending real money for the cluster,

 

Neither you neither Pine64 sellers is spending anything for software support (maintaining armbian and dealing with your problems = 50-70h per day). Keep that in mind when requesting help / support.

 

For start, attach a serial console and see what you have there.

[ichibrosan]

I was wondering if the Armbian distribution had a fix for this yet.  I downloaded the current sources and built

Armbian_20.08.0-trunk_Pine64so_buster_current_5.4.51.img

It does boot nicely in the baseboard but it does not appear to have any fix for the clustereboard networking problem.

 

I am able to use the 

Armbian_5.41_Pine64so_Ubuntu_xenial_next_4.14.20.img.xz

that I downloaded off the forum. It does have the fix, but if

I do the "apt update; apt upgrade" to bring in updates, I lose

the fix and the next boot fails to operate in the clusterboard.

 

Here is my Pine64 archive for community use.

see http://cloud.goodall.com/Pine64

 

The image I am using that has the fix (but cannot be updated) is

http://cloud.goodall.com/Pine64/ClusterBoard/Armbian_5.41_Pine64so_Ubuntu_xenial_next_4.14.20.img.xz

 

I will post updates in my archive as I have them so they will be available for use.

 

 

[lanefu]

@ichibrosan I don't believe anyone has provided a patch for the clusterboard.    Does the forum provide a patch?

[ichibrosan]

On 3/18/2019 at 4:47 AM, BryanS said:

 

That does seem to be the case. Hopefully this will change in the future - I really want to use this thing as a hardware docker-like device. If there's any information I can provide, please let me know.

I think the clusterboard is a great product. The only problem I have with it is this network issue and once solved, this will be a very easy integration.

Now that I have a provisionally working software load for the modules, it boots reliably and the modules are very responsive.

 

What I wish we had for now, is a script we can run after doing update and upgrade that will reinstall the device tree patch reboot rebooting.

If we had that, we could upgrade with an expectation that the system would come up after reboot.