siffland Posted January 21, 2019 Posted January 21, 2019 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 Posted January 24, 2019 Author Posted January 24, 2019 I also tried the debian strech 5.69 image and had the same results. Is there anything else i can try? Thanks, Sean
Igor Posted January 25, 2019 Posted January 25, 2019 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 Posted February 1, 2019 Posted February 1, 2019 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 Posted February 1, 2019 Posted February 1, 2019 On the above - forgot to mention - the dtb file that needs to be edited is "sun50i-a64-sopine-baseboard.dtb"
siffland Posted February 2, 2019 Author Posted February 2, 2019 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 Posted February 2, 2019 Author Posted February 2, 2019 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 Posted March 2, 2019 Posted March 2, 2019 so in the official images there is no fix applied for this issue?
BryanS Posted March 17, 2019 Posted March 17, 2019 @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 Posted March 18, 2019 Posted March 18, 2019 @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 Posted March 18, 2019 Posted March 18, 2019 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 Posted March 19, 2019 Author Posted March 19, 2019 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 Posted April 12, 2019 Posted April 12, 2019 @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 Posted April 22, 2019 Posted April 22, 2019 I'm not sure how to incorporate the new u-boot, but if I can figure it out I will test it.
Igor Posted April 22, 2019 Posted April 22, 2019 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 Posted April 25, 2019 Posted April 25, 2019 is it possible to just upgrade my image by apt upgrade? (defreeze kernel pkgs beforehand)
Igor Posted April 25, 2019 Posted April 25, 2019 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 Posted April 25, 2019 Posted April 25, 2019 okay...as i wanted to reinstall the boards i am going to test it this weekend
siffland Posted April 26, 2019 Author Posted April 26, 2019 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 1
AZClusterboard Posted April 27, 2019 Posted April 27, 2019 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 Posted April 27, 2019 Posted April 27, 2019 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 Posted April 27, 2019 Posted April 27, 2019 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 Posted April 27, 2019 Posted April 27, 2019 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 Posted June 25, 2019 Posted June 25, 2019 so reboots would work now on clusterboards if i update?
ichibrosan Posted June 12, 2020 Posted June 12, 2020 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 Posted June 13, 2020 Posted June 13, 2020 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 Posted July 12, 2020 Posted July 12, 2020 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 Posted July 13, 2020 Posted July 13, 2020 @ichibrosan I don't believe anyone has provided a patch for the clusterboard. Does the forum provide a patch?
Recommended Posts