-
Posts
28 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by Gavinb
-
-
Have a look at this topic:-
I did a patch myself to fix ethernet in u-boot on the Pine64-R18. I believe it's a problem with most of the sun50xi configuration files.
-
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
Pine64-R18 - Setup GPIO inputs via Device Tree
in Pine A64
Posted
Hi
I have been trying to allocate specific gpio's as input via the Device Tree, this ultimately being for a custom made board.
I can and have successfully allocated pins PB0, PB1, PB3 & PB5, which are showing in /dev/inputs/by-path and have been verified working with evtest.
Working code :-
/dts-v1/; /plugin/; / { fragment@0 { target = <&pio>; __overlay__ { input_0: input_0 { pins = "PB0"; function = "gpio_in"; bias-pull-up; }; }; }; fragment@1 { target-path = "/"; __overlay__ { button_1 { compatible = "gpio-keys"; pinctrl-names = "default"; pinctrl-0 = <&input_0>; Button_1 { label = "Button_1"; linux,code = <2>; gpios = <&pio 1 0 1>; }; }; }; }; };
However, I need to use GPIO PG2, PG3 PG4 & PG5.
When changing the allocation, both 'pins = "PB0";' in fragment0 and 'gpios = <&pio 1 0 1>;' to PG2 and &pio 6 2 1, then overlay is successfully installed, but however not working.
/dts-v1/; /plugin/; / { fragment@0 { target = <&pio>; __overlay__ { input_0: input_0 { pins = "PG2"; function = "gpio_in"; bias-pull-up; }; }; }; fragment@1 { target-path = "/"; __overlay__ { button_1 { compatible = "gpio-keys"; pinctrl-names = "default"; pinctrl-0 = <&input_0>; Button_1 { label = "Button_1"; linux,code = <2>; gpios = <&pio 6 2 1>; }; }; }; }; };
I have verified that the pins I intend to use are in fact IRQ pins, and can control the pins via sysfs, by manually exporting, setup and echo to toggle them.
I've haven't seen anything that stands out in the balance of the std Device Tree structure that might be causing this issue.
Any suggestions as to where else I could look into resolving this would be appreciated.
Regards
Gavin B