Alaric Posted December 15, 2017 Posted December 15, 2017 HI, I built the latest images for the Pine64+ & Pine64so - kernel 4.14.x + Debian 9 using the Armbian build scripts and had a problem with the ethernet not operational. Any help would greatly be appreciated. U-Boot SPL 2017.11-armbian (Dec 13 2017 - 23:42:42) DRAM: 2048 MiB Trying to boot from MMC1 NOTICE: BL3-1: Running on A64/H64 (1689) in SRAM A2 (@0x44000) NOTICE: Configuring SPC Controller NOTICE: BL3-1: v1.0(debug):aa75c8d NOTICE: BL3-1: Built : 23:41:50, Dec 13 2017 NOTICE: Configuring AXP PMIC NOTICE: PMIC: setup successful INFO: BL3-1: Initializing runtime services INFO: BL3-1: Preparing for EL3 exit to normal world INFO: BL3-1: Next image address: 0x4a000000, SPSR: 0x3c9 U-Boot 2017.11-armbian (Dec 13 2017 - 23:42:42 +0200) Allwinner Technology CPU: Allwinner A64 (SUN50I) Model: SoPine with baseboard DRAM: 2 GiB MMC: SUNXI SD/MMC: 0, SUNXI SD/MMC: 1 Card did not respond to voltage select! mmc_init: -95, time 22 *** Warning - MMC init failed, using default environment In: serial Out: serial Err: serialNet: No ethernet found. 230454 bytes read in 142 ms (1.5 MiB/s) starting USB... USB0: USB EHCI 0.00 USB1: USB OHCI 0.0 USB2: PA: set_value: error: gpio PA0 not reserved USB EHCI 1.00 USB3: USB OHCI 1.0 scanning bus 0 for devices... 1 USB Device(s) found scanning bus 2 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Autoboot in 1 seconds, press <Space> to stop ..... Thanks, Alaric
Igor Posted December 15, 2017 Posted December 15, 2017 8 minutes ago, Alaric said: Any help would greatly be appreciated. Likewise. There was a regression in network stack on H5 boards and apparently on A64 in a recent transformation from 4.13.y to 4.14.y. This kernel is still in development, for testing at most & thanks for reporting the problem. If you need a working board, stick to the legacy kernel or get involved in development to fix this problem.
Alaric Posted December 15, 2017 Author Posted December 15, 2017 Hi Igor, If we use kernel 4.4 would this solve this problem?
Igor Posted December 15, 2017 Posted December 15, 2017 A network was working in 4.13.y and we don't have another kernel for this board/chip. If you refer to recent Allwinner 4.4.y ... waste of time. There is no instant solution except the already mentioned legacy kernel. Edit: btw this - what you ask - is u-boot related and I don't know if we have network support there yet. 1
mz-fuzzy Posted January 3, 2018 Posted January 3, 2018 Hi, today's attempt with pine64+, 'next' branch build. It seems that uboot detects ethernet: U-Boot SPL 2017.11-armbian (Jan 03 2018 - 17:47:48) DRAM: 2048 MiB Trying to boot from MMC1 NOTICE: BL3-1: Running on A64/H64 (1689) in SRAM A2 (@0x44000) NOTICE: Configuring SPC Controller NOTICE: BL3-1: v1.0(debug):aa75c8d NOTICE: BL3-1: Built : 17:47:41, Jan 3 2018 NOTICE: Configuring AXP PMIC NOTICE: PMIC: Output power control 2 is an unexpected 0x0 ERROR: PMIC: setup failed: -3 INFO: BL3-1: Initializing runtime services INFO: BL3-1: Preparing for EL3 exit to normal world INFO: BL3-1: Next image address: 0x4a000000, SPSR: 0x3c9 U-Boot 2017.11-armbian (Jan 03 2018 - 17:47:48 +0000) Allwinner Technology CPU: Allwinner A64 (SUN50I) Model: Pine64+ DRAM: 2 GiB MMC: SUNXI SD/MMC: 0 *** Warning - bad CRC, using default environment Warning: HDMI PHY init timeout! Warning: HDMI PHY init timeout! In: serial Out: serial Err: serial Net: phy interface7 eth0: ethernet@01c30000 230454 bytes read in 142 ms (1.5 MiB/s) Warning: HDMI PHY init timeout! starting USB... USB0: PA: set_value: error: gpio PA0 not reserved USB EHCI 1.00 USB1: USB OHCI 1.0 scanning bus 0 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Autoboot in 1 seconds, press <Space> to stop but no ethernet interface success with the kernel: ... [ 1.636825] libphy: Fixed MDIO Bus: probed [ 1.637114] dwmac-sun8i 1c30000.ethernet: could not find pctldev for node /soc/pinctrl@1c20800/rgmii_pins, deferring probe [ 1.637537] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ... ... [ 1.785232] console [ttyS0] enabled [ 1.785955] dwmac-sun8i 1c30000.ethernet: PTP uses main clock [ 1.786174] dwmac-sun8i 1c30000.ethernet: Current syscon value is not the default 6 (expect 0) [ 1.786184] dwmac-sun8i 1c30000.ethernet: Unsupported interface mode: rgmii-txid [ 1.786347] dwmac-sun8i: probe of 1c30000.ethernet failed with error -12 [ 1.786702] ehci-platform 1c1b000.usb: EHCI Host Controller ... any idea? Thanks, Bob
Igor Posted January 3, 2018 Posted January 3, 2018 1 hour ago, bob said: any idea? Yes. The network is broken due to changes in the upstream kernel driver code. I managed to port this fix to H3 & H5 from 4.15.y while AFAIK A64 is still broken. Perhaps @montjoie know more about this? 1
montjoie Posted January 4, 2018 Posted January 4, 2018 Hello I see two potential problem: - Unsupported interface mode: rgmii-txid Check your DTB, (the one in linux-next is good) - could not find pctldev for node /soc/pinctrl@1c20800/rgmii_pins Check that you have AXP stuff enabled CONFIG_AXP20X_POWER=y CONFIG_AXP20X_ADC=y CONFIG_REGULATOR_AXP20X=y Do not hesitate to contact me on IRC/freenode/#linux-sunxi
zador.blood.stained Posted January 4, 2018 Posted January 4, 2018 19 minutes ago, montjoie said: - Unsupported interface mode: rgmii-txid Check your DTB, (the one in linux-next is good) Most likely this was left over from Icenowy's patch: https://groups.google.com/forum/#!topic/linux-sunxi/V7HE8OL2p3c 20 minutes ago, montjoie said: - could not find pctldev for node /soc/pinctrl@1c20800/rgmii_pins Deferring probe due to pinctrl driver at early boot is normal, hard to say if we have a real issue without full dmesg.
mz-fuzzy Posted January 4, 2018 Posted January 4, 2018 8 hours ago, zador.blood.stained said: 8 hours ago, montjoie said: - Unsupported interface mode: rgmii-txid Check your DTB, (the one in linux-next is good) Most likely this was left over from Icenowy's patch: https://groups.google.com/forum/#!topic/linux-sunxi/V7HE8OL2p3c yes, it seems that this part of the patch is not upstreamed: https://github.com/CallMeFoxie/linux/commit/97684c600f9e848af9e6e417155c8e0683dcd410 and I guess this causes inconsistency/failure for pine64+.
zador.blood.stained Posted January 4, 2018 Posted January 4, 2018 8 minutes ago, bob said: yes, it seems that this part of the patch is not upstreamed Last time I heard part of this patch set (Realtek PHY configuration for delays) may not be upstreamed at all: https://irclog.whitequark.org/linux-sunxi/2017-12-26#20898330;
mz-fuzzy Posted January 4, 2018 Posted January 4, 2018 13 minutes ago, zador.blood.stained said: Last time I heard part of this patch set (Realtek PHY configuration for delays) may not be upstreamed at all: https://irclog.whitequark.org/linux-sunxi/2017-12-26#20898330; hm, but then the pine64+ code is inconsistent upstream... I guess that should be patched in armbian, right? I would like to test that, do you have any suggestion how to apply that patch easiest so I can build and test? To create a new patch in patch/kernel/sunxi-next/...? Well that impacted file is already being patched in sunxi-network-dwmac-sun8i_backport_from_4.15-rc.patch...
Igor Posted January 7, 2018 Posted January 7, 2018 On 4. 1. 2018 at 7:42 PM, bob said: To create a new patch in patch/kernel/sunxi-next/. Two options. Start a compilation with CREATE_PATCHES="yes" and edit the code manually when asked ... or add already aligned appropriate patch to userpatches/kernel/sunxi-next ...
mz-fuzzy Posted January 7, 2018 Posted January 7, 2018 7 hours ago, Igor said: Start a compilation with CREATE_PATCHES="yes" and edit the code manually when asked cool mechanism. After patching the code, mainline pine64+ seems to be working for me including ethernet! Is it ok to submit that patch as a pull request to armbian? Thanks! -bob- 1
Igor Posted January 7, 2018 Posted January 7, 2018 5 minutes ago, bob said: Is it ok to submit that patch as a pull request to armbian? Of course. Great job!
mz-fuzzy Posted January 7, 2018 Posted January 7, 2018 @Igor after closer look, the whole thing is a bit different than I thought originally. It seems that the code inconsistency was introduced by other patch in armbian, but the pine64 ethernet patch is pretty much missing. So, for now I removed that part of patch so the ethernet is consistent (PR submitted). Pine64 Ethernet patch is still to be added there. I can work on that. -bob-
mz-fuzzy Posted January 8, 2018 Posted January 8, 2018 Icenowy's 4.14 ethernet patches included and tested, working nicely for me, no retransmits, full Gb speed. PR sumbitted.
Xalius Posted January 8, 2018 Posted January 8, 2018 I am investigating a weird issue I have with SOPine modules at the moment, GbE works fine on the Baseboard A with 4.15-rc6, but not on clusterboard, I also have an issue with MAC address assignment where the interface drops into monitor mode after a while... 1
Gavinb Posted May 4, 2018 Posted May 4, 2018 Hi everyone, Have spent most of the day working on this one, and have found the following:- Pine64A+, built the image (Pine64), All is working well, including ethernet in U-Boot. Pine64-R18, built the image (Pine64so), The image works well, ethernet works in the kernel, however, ethernet was not available via U-Boot (Which is what is required by me). I compared the device tree configurations within U-Boot between the boards, found the difference between them regarding ethernet configuration and applied the follow patch which then enabled ethernet in U-Boot. diff --git a/arch/arm/dts/sun50i-a64-sopine-baseboard.dts b/arch/arm/dts/sun50i-a64-sopine-baseboard.dts index 42c0f10..1c7c04a 100644 --- a/arch/arm/dts/sun50i-a64-sopine-baseboard.dts +++ b/arch/arm/dts/sun50i-a64-sopine-baseboard.dts @@ -46,6 +46,7 @@ /dts-v1/; #include "sun50i-a64-sopine.dtsi" +#include <dt-bindings/gpio/gpio.h> / { model = "SoPine with baseboard"; @@ -54,6 +55,7 @@ aliases { serial0 = &uart0; + ethernet0 = &emac; }; chosen { @@ -66,6 +68,51 @@ regulator-min-microvolt = <1800000>; regulator-max-microvolt = <1800000>; }; + + soc { + emac: ethernet@01c30000 { + compatible = "allwinner,sun50i-a64-emac"; + reg = <0x01c30000 0x2000>, <0x01c00030 0x4>; + reg-names = "emac", "syscon"; + interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>; + resets = <&ccu RST_BUS_EMAC>; + reset-names = "ahb"; + clocks = <&ccu CLK_BUS_EMAC>; + clock-names = "ahb"; + #address-cells = <1>; + #size-cells = <0>; + pinctrl-names = "default"; + pinctrl-0 = <&rgmii_pins>; + phy-mode = "rgmii"; + phy = <&phy1>; + status = "okay"; + + phy1: ethernet-phy@1 { + reg = <1>; + }; + }; + }; +}; + +&pio { + rmii_pins: rmii_pins { + allwinner,pins = "PD10", "PD11", "PD13", "PD14", + "PD17", "PD18", "PD19", "PD20", + "PD22", "PD23"; + allwinner,function = "emac"; + allwinner,drive = <3>; + allwinner,pull = <0>; + }; + + rgmii_pins: rgmii_pins { + allwinner,pins = "PD8", "PD9", "PD10", "PD11", + "PD12", "PD13", "PD15", + "PD16", "PD17", "PD18", "PD19", + "PD20", "PD21", "PD22", "PD23"; + allwinner,function = "emac"; + allwinner,drive = <3>; + allwinner,pull = <0>; + }; }; &ehci0 { @@ -100,3 +147,7 @@ pinctrl-0 = <&uart0_pins_a>; status = "okay"; }; + +&usbphy { + status = "okay"; +}; My question now is, am I doing things correctly, if so, how would I go about submitting this as a patch, to be including in later builds of armbian? Regards Gavin
Recommended Posts