Search the Community

Good day to you))) I have a TV BOX TX9Pro. Chassis (Main Board): H616/H313mini84 V2.0 kernel 4.9.170 I would like to run one of the armbian builds on it. But I can’t figure out how to do this, here are the logs when starting the console... Is there support for this device? tell me what to do and how... Thanks in advance. U-Boot SPL 2021.04 (May 25 2023 - 13:03:46 +0200) DRAM:This DRAM setup is currently not supported. resetting ... [70]HELLO! BOOT0 is starting! [73]BOOT0 commit : 803d783 [75]set pll start [78]periph0 has been enabled [81]set pll end [83]unknow PMU [84]unknow PMU [86]PMU: AXP1530 [88]dram return write ok [90]board init ok [92]DRAM BOOT DRIVE INFO: V0.645 [96]the chip id is 0x5d00 [98]chip id check OK [103]DRAM_VCC set to 1500 mv [106]DRAM CLK =600 MHZ [108]DRAM Type =3 (3:DDR3,4:DDR4,7:LPDDR3,8:LPDDR4) [116]Actual DRAM SIZE =1024 M [118]DRAM SIZE =1024 MBytes, para1 = 30eb, para2 = 4000000, dram_tpr13 = 6041 [132]DRAM simple test OK. [134]rtc standby flag is 0x0, super standby flag is 0x0 [140]dram size =1024 [143]card no is 2 [145]sdcard 2 line count 8 [147][mmc]: mmc driver ver 2020-09-10 15:32 [157][mmc]: Wrong media type 0x0, but host sdc2, try mmc first [163][mmc]: ***Try MMC card 2*** [202][mmc]: RMCA OK! [204][mmc]: bias 4 [207][mmc]: MMC 5.0 [209][mmc]: HSSDR52/SDR25 8 bit [212][mmc]: 50000000 Hz [214][mmc]: 7456 MB [216][mmc]: ***SD/MMC 2 init OK!!!*** [291]Loading boot-pkg Succeed(index=0). [294]Entry_name = u-boot [304]Entry_name = monitor [307]Entry_name = dtbo [310]Entry_name = dtb [314]tunning data addr:0x4a0003e8 [317]Jump to second Boot. NOTICE: BL3-1: v1.0(debug):a0d3abd NOTICE: BL3-1: Built : 17:32:02, 2020-10-20 NOTICE: BL3-1 commit: 8 ERROR: Error initializing runtime service tspd_fast NOTICE: BL3-1: Preparing for EL3 exit to normal world NOTICE: BL3-1: Next image address = 0x4a000000 NOTICE: BL3-1: Next image spsr = 0x1d3 U-Boot 2018.05 (Feb 15 2023 - 17:22:04 +0800) Allwinner Technology [00.391]CPU: Allwinner Family [00.394]Model: sun50iw9 I2C: ready [00.398]DRAM: 1 GiB [00.401]Relocation Offset is: 35ebf000 [00.442]secure enable bit: 0 [00.444]pmu_axp152_probe pmic_bus_read fail [00.448]PMU: AXP1530 [00.454]CPU=1008 MHz,PLL6=600 Mhz,AHB=200 Mhz, APB1=100Mhz MBus=400Mhz [00.462]drv_disp_init [00.492]__clk_enable: clk is null. [00.497]drv_disp_init finish [00.500]gic: sec monitor mode [00.522]flash init start [00.524]workmode = 0,storage type = 2 [00.528]MMC: 2 [00.529][mmc]: mmc driver ver uboot2018:2021-07-19 14:09:00 [00.535][mmc]: get sdc_type fail and use default host:tm4. [00.546][mmc]: SUNXI SDMMC Controller Version:0x40502 [00.590][mmc]: Best spd md: 4-HS400, freq: 3-100000000, Bus width: 8 [00.596]sunxi flash init ok [00.600]Loading Environment from SUNXI_FLASH... OK [00.609]usb burn from boot delay time 0 weak:otg_phy_config [00.623]usb prepare ok [01.426]overtime [01.430]do_burn_from_boot usb : no usb exist [01.434]boot_gui_init:start FAT: Misaligned buffer address (7be7be58) 32 bytes read in 4 ms (7.8 KiB/s) tcon_de_attach:de=0,tcon=2[01.567]boot_gui_init:finish [01.570]bmp_name=bootlogo.bmp 2764854 bytes read in 40 ms (65.9 MiB/s) [01.633]update dts ** Unrecognized filesystem type ** [01.642]load file(ULI/factory/rootwait init.txt) error. ** Unrecognized filesystem type ** [01.655]load file(ULI/factory/snum.txt) error. [01.659]name in map mac ** Unrecognized filesystem type ** [01.668]load file(ULI/factory/wifi_mac.txt) error. ** Unrecognized filesystem type ** [01.680]load file(ULI/factory/bt_mac.txt) error. ** Unrecognized filesystem type ** [01.692]load file(ULI/factory/selinux.txt) error. ** Unrecognized filesystem type ** [01.704]load file(ULI/factory/specialstr.txt) error. [01.713]update part info [01.738]update bootcmd [01.740]No ethernet found. Hit any key to stop autoboot: 0 [02.050]Starting kernel ... [02.053][mmc]: mmc exit start [02.101][mmc]: mmc 2 exit ok [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 4.9.170 (akrd6@R740XD) (gcc version 5.3.1 20160412(Linaro GCC 5.3-2016.05) ) #80 SMP PREEMPT Wed Feb 15 17:22:30 CST 2023 [ 0.000000] Boot CPU: AArch64 Processor [410fd034] [ 0.000000] bootconsole [earlycon0] enabled [ 0.027874] BOOTEVENT: 27.858249: ON [ 0.242175] sunxi_i2c_probe()2209 - [i2c3] warning: failed to get regulator d [ 0.243164] sunxi_i2c_probe()2209 - [i2c5] warning: failed to get regulator d [ 0.244517] axp2101-regulator axp2101-regulator.0: Setting DCDC frequency fo unsupported AXP variant [ 0.244601] axp2101-regulator axp2101-regulator.0: Error setting dcdc frequecy: -22 [ 0.279245] [ac200] get ave_regulator_name failed! [ 0.279751] [ac200] pwm enable [ 0.363211] gpio_pin_4(229) gpio_request fail [ ▒[ 0.369727] uart uart1: get regulator failed [ 0.402346] [NAND][NE] Not found valid nand node on dts [ 0.411005] sunxi-wlan soc@03000000:wlan: get gpio chip_en failed [ 0.417894] sunxi-wlan soc@03000000:wlan: get gpio power_en failed [ 0.550010] hci: request ohci1-controller gpio:232 [ 0.742282] axp2101_pek: axp2101-pek can not register without irq [ 0.752785] sunxi_ir_startup: get ir protocol failed [ 0.761135] VE: get debugfs_mpp_root is NULL, please check mpp [ 0.761135] [ 0.769395] VE: sunxi ve debug register driver failed! [ 0.769395] [ 0.784659] mmc:failed to get gpios [ 0.865627] mmc:failed to get gpios [ 0.901895] FD655: ==fd655_driver_probe==================== [ 0.908284] FD655: : (null) [ 0.909038] sunxi-mmc sdc1: smc 2 p1 err, cmd 52, RTO !! [ 0.912260] sunxi-mmc sdc1: smc 2 p1 err, cmd 52, RTO !! [ 0.926757] FD655: : (null) [ 0.929915] sunxi-mmc sdc1: smc 2 p1 err, cmd 5, RTO !! [ 0.935814] sunxi-mmc sdc1: smc 2 p1 err, cmd 5, RTO !! [ 0.941713] sunxi-mmc sdc1: smc 2 p1 err, cmd 5, RTO !! [ 0.947606] sunxi-mmc sdc1: smc 2 p1 err, cmd 5, RTO !! [ 0.953859] FD655: register_fd655_driver: Successed to add fd655 module [ 0.973520] failed get gpio-spdif gpio from dts,spdif_gpio:-2 [ 0.983217] [audio-codec]dachpf_cfg configurations missing or invalid. [ 0.990865] lineout_vol:26, linein_gain:3, fmin_gain:3, digital_vol:0, adcdr_cfg:0, adchpf_cfg:0, dacdrc_cfg:0, dachpf_cfg:0, ramp_func_used:1, pa_msleep_tme:160, pa_ctl_level:0, gpio-spk:0 [ 1.014903] sndhdmi sndhdmi: ASoC: CPU DAI (null) not registered [ 1.021698] sndhdmi sndhdmi: snd_soc_register_card() failed: -517 [ 1.035293] sunxi-ahub-cpudai 5097000.cpudai3-controller: ahub cpudai id invlid [ 1.068733] ERROR: pinctrl_get for HDMI2.0 DDC fail [ 1.078344] tv_probe()1435 - of_property_read_string tv_power failed! [ 1.174637] cpu cpu1: opp_list_debug_create_link: Failed to create link [ 1.182156] cpu cpu1: _add_opp_dev: Failed to register opp debugfs (-12) [ 1.189771] cpu cpu2: opp_list_debug_create_link: Failed to create link [ 1.197234] cpu cpu2: _add_opp_dev: Failed to register opp debugfs (-12) [ 1.204828] cpu cpu3: opp_list_debug_create_link: Failed to create link [ 1.212279] cpu cpu3: _add_opp_dev: Failed to register opp debugfs (-12) [ 1.684491] selinux: avc: denied { set } for scontext=u:r:vendor_init:s0 context=u:object_r:default_prop:s0 tclass=property_service permissive=1 [ 1.684491] [ 1.702686] selinux: avc: denied { set } for scontext=u:r:vendor_init:s0 context=u:object_r:dalvik_prop:s0 tclass=property_service permissive=1 [ 1.702686] [ 2.576915] FAT-fs (mmcblk0p15): bogus number of reserved sectors console:/ $ [ 8.720978] apexd: Failed to walk /product/apex : Can't open /prduct/apex for reading : No such file or directory ^C 130|console:/ $ [ 22.711942] sunxi-mmc sdc1: smc 2 p1 err, cmd 52, RTO !! [ 22.913822] SSV6XXX_SDIO mmc2:0001:1: vendor = 0x3030 device = 0x3030 [ 22.947618] SSV6XXX_SDIO mmc2:0001:1: dataIOPort 0x10000 regIOPort 0x10020 [ 22.958352] sunxi-mmc sdc1: smc 2 p1 err, cmd 52, RE RCE !! [ 23.030814] SSV6XXX_SDIO mmc2:0001:1: dataIOPort 0x10000 regIOPort 0x10020 [ 23.057388] SSV6XXX HCI TX Task started. [ 23.135876] Enable HCI TX aggregation [ 24.042450] SSV WLAN driver SSV6006C: Set new macaddr [ 24.060821] SSV WLAN driver SSV6006C: VIF 08:1a:1e:fd:85:e4 of type 2 is added. [ 25.361805] SSV WLAN driver SSV6006C: Set new macaddr [ 25.386662] SSV WLAN driver SSV6006C: VIF 08:1a:1e:fd:85:e5 of type 2 is added. [ 27.173711] selinux: avc: denied { set } for property=sys.config.rootservice pid=2978 uid=0 gid=0 scontext=u:r:rootservice:s0 tcontext=u:object_r:system_prop:s0 tclass=property_service permissive=1 [ 27.173711] [ 27.207603] audit: rate limit exceeded [ 30.214797] apexd: Can't open /product/apex for reading : No such file or directory U-Boot SPL 2021.04 (May 25 2023 - 13:03:46 +0200) /system/bin/sh: syntax error: unexpected '(' 1|console:/ $ DRAM:This DRAM setup is currently not supported. /system/bin/sh: DRAM:This: inaccessible or not found 127|console:/ $ [ 34.750480] selinux: avc: denied { set } for property=supolicy.loaded pid=3902 uid=0 gid=0 scontext=u:r:toolbox:s0 tcontext=u:object_r:default_prop:s0 tclass=property_service permissive=1 [ 34.750480] U-Boot SPL 2021.04 (May 25 2023 - 13:03:46 +0200) /system/bin/sh: syntax error: unexpected '(' 1|console:/ $ DRAM:This DRAM setup is currently not supported. /system/bin/sh: DRAM:This: inaccessible or not found 127|console:/ $

i want to use led on/off 7 pin (gpio 40 header) but it doesn’t work. Others work fine: echo 20 > /sys/class/gpio/export echo 23 > /sys/class/gpio/export echo 40 > /sys/class/gpio/export echo 42 > /sys/class/gpio/export echo out > /sys/class/gpio/gpio20/direction echo out > /sys/class/gpio/gpio23/direction echo out > /sys/class/gpio/gpio40/direction echo out > /sys/class/gpio/gpio42/direction echo 1 > /sys/class/gpio/gpio20/value echo 1 > /sys/class/gpio/gpio23/value echo 1 > /sys/class/gpio/gpio40/value echo 1 > /sys/class/gpio/gpio42/value May be problem in pwm10 pwm10 { pwm10m0-pins { rockchip,pins = <0x03 0x0d 0x05 0xab>; phandle = <0x9d>; }; pwm10m1-pins { rockchip,pins = <0x02 0x01 0x02 0xab>; phandle = <0x1f5>; }; dts attached from firmware - https://www.armbian.com/bananapi-r2-pro/ r2pro.dts

@greg396 WiringOP? WiringOP isn't mentioned in this topic as it isn't necessary. AFAIK is the green wire (RPM) only feedback of the actual RPM which will not be used. In case of the OPI5 I'm not sure if there'll be 5v on the PWM wire, if that's the case you might break the OPI5 by connecting it to the GPIO pins (3.3v), otherwise you can try it. In case you have the OPI5 plus you can try to connect it as in:

usual user, I compiled the "con1" dtso you provided, but I didn't integrate it in the whole SBC dtb. I left it as a dtbo and copied it to the user overlays... it worked and I have the opiz3 gpio pins named 😄 As a reminder, here's how to do it: {start with a fresh armbian OS, or make sure that the orangepizero3 dtb is the original} # cat /sys/kernel/debug/gpio {check that the GPIO pins are not named} {copy the dtso to /boot/user-overlays} # dtc --in-format dts sun50i-h618-orangepi-zero3-con1.dtso --out sun50i-h618-orangepi-zero3-con1.dtbo # ls -l total 8 -rw-r--r-- 1 root root 591 Feb 18 01:35 sun50i-h618-orangepi-zero3-con1.dtbo -rw-r--r-- 1 root root 1374 Feb 17 22:36 sun50i-h618-orangepi-zero3-con1.dtso # nano /boot/armbianEnv.txt {add line: user_overlays=sun50i-h618-orangepi-zero3-con1} # reboot # cat /sys/kernel/debug/gpio {the gpio pins are named} I was expecting it that the user overlays appear in the armbian-config utility... but my dtbo didnt show in the system>hardware selection options... is this normal? To any newbie trying this: be careful of conflicts in activating a kernel-provided overlay and a user overlay at the same time: https://docs.armbian.com/User-Guide_Allwinner_overlays/ I just noticed that there's a February 15 linux image... I will try that Update... the compiled dtso did not work for the new linux OS image... uboot could not overlay the dtbo and I noticed that it uses a different dtb... what should I do to update the dtso and make it work? sun50i-h618-orangepi-zero3.dtb HOWEVER: the DTSO works when applying it in the DTB, as you suggested. It is only when trying to apply the DTBO with uboot, it fails. Unfortuately, the linux os freezes after 10 minutes or so nevermind... it maybe another cause...

I'm familiar with ARMbian on Orange PI 3, more specifically I'm trying to master programming in C on this system and hw. Since yesterday I've been searching in vain for some description, ideally with examples of how to control GPIO, I2C and SPI in C. Can you advise?

I know this is about zero 3, but the 2W works just as well with the same image, someone knows of a way to get audio out via the PWM1 and PWM2 GPIO pins of the 2W?

Hello everyone, I encountered an issue while using SPI with my Orange Pi 3 LTS, and now I'm going to share some solutions. Perhaps the Armbian Team can assist me in resolving the final problem. These tests were conducted on Armbian 23.02.2 Bullseye with Linux 5.15.93-sunxi64. The initial step I took to ensure the appearance of `spidev` on the Orange Pi 3 LTS was to include these configurations in `/boot/armbianEnv.txt`. overlays=spi-spidev1 param_spidev_spi_bus=0 param_spidev_spi_cs=0 Note: If `spi-spidev` and `spi-spidev1` are added together, it will not work, and the `spidev` will not appear when using the `ls /dev/sp*` command. After performing the above steps, I executed the `sudo reboot` command, and `/dev/spidev1.0` appeared. root@orangepi3-lts:~/wiringOP# ls /dev/sp* /dev/spidev1.0 However, this alone was insufficient to ensure proper functionality of SPI. I attempted to send a message to an ATMega 168p using a Python script that utilizes the `spidev` library. The script is below: import spidev spi = spidev.SpiDev() spi.open(1, 0) spi.max_speed_hz=10000 payload = [0x0c, 0x00] spi.xfer(payload) print(*payload[1:]) The ATMega 168p occasionally received the message, and sometimes it did not. I suspected that the issue might be related to the MISO or MOSI connections. To investigate further, I directly connected the MISO pin of the Orange Pi 3 LTS to its MOSI pin, testing whether I would receive an echo in the script provided earlier. Indeed, I received the echo successfully. Considering the observations so far, my remaining suspicion lies with the CS (Chip Select) line. If the CS line is not functioning properly, it may fail to select the specific device, resulting in issues with the request/response process (similar to what I experienced). Hence, I proceeded to install wiringOp, on my device. This allowed me to read all the GPIOs of my Orange Pi 3 LTS and check for any anomalies. After successfully building it, I ran the command `gpio readall` and observed the following output: root@orangepi3-lts:~/wiringOP# gpio readall +------+-----+----------+------+---+ OPi 3 +---+------+----------+-----+------+ | GPIO | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | GPIO | +------+-----+----------+------+---+----++----+---+------+----------+-----+------+ | | | 3.3V | | | 1 || 2 | | | 5V | | | | 122 | 0 | SDA.0 | OFF | 0 | 3 || 4 | | | 5V | | | | 121 | 1 | SCL.0 | OFF | 0 | 5 || 6 | | | GND | | | | 118 | 2 | PWM.0 | OFF | 0 | 7 || 8 | 0 | OFF | PL02 | 3 | 354 | | | | GND | | | 9 || 10 | 0 | OFF | PL03 | 4 | 355 | | 120 | 5 | RXD.3 | OFF | 0 | 11 || 12 | 0 | OFF | PD18 | 6 | 114 | | 119 | 7 | TXD.3 | OFF | 0 | 13 || 14 | | | GND | | | | 362 | 8 | PL10 | OFF | 0 | 15 || 16 | 0 | OFF | PD15 | 9 | 111 | | | | 3.3V | | | 17 || 18 | 0 | OFF | PD16 | 10 | 112 | | 229 | 11 | MOSI.1 | ALT2 | 0 | 19 || 20 | | | GND | | | | 230 | 12 | MISO.1 | ALT2 | 0 | 21 || 22 | 0 | OFF | PD21 | 13 | 117 | | 228 | 14 | SCLK.1 | ALT2 | 0 | 23 || 24 | 0 | OFF | CE.1 | 15 | 227 | | | | GND | | | 25 || 26 | 0 | OFF | PL08 | 16 | 360 | +------+-----+----------+------+---+----++----+---+------+----------+-----+------+ | GPIO | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | GPIO | +------+-----+----------+------+---+ OPi 3 +---+------+----------+-----+------+ I noticed that the CS pin (GPIO 227) is currently set to `OFF` and needs to be configured as `ALT2` along with `MOSI.1`, `MISO.1`, and `SCLK.1` . This information gave me a clear direction on how to solve my problem. To investigate further, I began checking the device tree configuration using the following commands: `sudo armbian-config` -> `System` -> `Dtc`: ... spi1-pins { pins = "PH4\0PH5\0PH6"; function = "spi1"; phandle = <0x2b>; }; spi1-cs-pin { pins = "PH3"; function = "spi1"; phandle = <0x2c>; }; ... spi@5011000 { compatible = "allwinner,sun50i-h6-spi\0allwinner,sun8i-h3-spi"; reg = <0x5011000 0x1000>; interrupts = <0x00 0x0b 0x04>; clocks = <0x04 0x53 0x04 0x51>; clock-names = "ahb\0mod"; dmas = <0x2a 0x17 0x2a 0x17>; dma-names = "rx\0tx"; pinctrl-names = "default"; pinctrl-0 = <0x2b 0x2c>; resets = <0x04 0x20>; status = "disabled"; #address-cells = <0x01>; #size-cells = <0x00>; phandle = <0x72>; }; ... Upon examining the pinout diagram, I realized that the Orange Pi 3 LTS utilizes SPI1, and all the SPI pins (H3, H4, H5, H6) were correctly configured in the device tree. This led me to speculate that the issue might not be in the device tree itself but rather in the `spi-spidev1 overlay`. To investigate further, I decompiled the `sun50i-h6-spi-spidev1.dtbo` file located at `/boot/dtb/allwinner/overlay/` into a `.dts` file using the command `dtc -I dtb -O dts sun50i-h6-spi-spidev1.dtbo -o sun50i-h6-sp i-spidev1.dts`. Next, I edited the `pinctrl-0` section of the `sun50i-h6-spi-spidev1.dts` file, adding the addresses `0x2b` and `0x2c` (similar to what was done in spi@5011000). /dts-v1/; / { compatible = "allwinner,sun8i-h3-spi"; fragment@0 { target-path = "/aliases"; __overlay__ { spi1 = "/soc/spi@5011000"; }; }; fragment@1 { target = <0xffffffff>; __overlay__ { pinctrl-names = "default"; pinctrl-0 = <0x2b 0x2c>; status = "okay"; #address-cells = <0x01>; #size-cells = <0x00>; spidev@0 { compatible = "armbian,spi-dev"; reg = <0x00>; spi-max-frequency = <0xf4240>; }; }; }; __fixups__ { spi1 = "/fragment@1:target:0"; spi1_pins = "/fragment@1/__overlay__:pinctrl-0:0"; }; }; Compiled the modified `sun50i-h6-spi-spidev1.dts` file into a `.dtbo` using the command `dtc -O dtb -I dts sun50i-h6-spi-spidev1.dts -o sun50i-h6-spi-spidev1.dtbo`. Then, I rebooted the Orange Pi 3 LTS. After the reboot, I ran the `gpio readall` command again to check the GPIO pin status: root@orangepi3-lts:~# gpio readall +------+-----+----------+------+---+ OPi 3 +---+------+----------+-----+------+ | GPIO | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | GPIO | +------+-----+----------+------+---+----++----+---+------+----------+-----+------+ | | | 3.3V | | | 1 || 2 | | | 5V | | | | 122 | 0 | SDA.0 | OFF | 0 | 3 || 4 | | | 5V | | | | 121 | 1 | SCL.0 | OFF | 0 | 5 || 6 | | | GND | | | | 118 | 2 | PWM.0 | OFF | 0 | 7 || 8 | 0 | OFF | PL02 | 3 | 354 | | | | GND | | | 9 || 10 | 0 | OFF | PL03 | 4 | 355 | | 120 | 5 | RXD.3 | OFF | 0 | 11 || 12 | 0 | OFF | PD18 | 6 | 114 | | 119 | 7 | TXD.3 | OFF | 0 | 13 || 14 | | | GND | | | | 362 | 8 | PL10 | OFF | 0 | 15 || 16 | 0 | OFF | PD15 | 9 | 111 | | | | 3.3V | | | 17 || 18 | 0 | OFF | PD16 | 10 | 112 | | 229 | 11 | MOSI.1 | ALT2 | 0 | 19 || 20 | | | GND | | | | 230 | 12 | MISO.1 | ALT2 | 0 | 21 || 22 | 0 | OFF | PD21 | 13 | 117 | | 228 | 14 | SCLK.1 | ALT2 | 0 | 23 || 24 | 0 | ALT2 | CE.1 | 15 | 227 | | | | GND | | | 25 || 26 | 0 | OFF | PL08 | 16 | 360 | +------+-----+----------+------+---+----++----+---+------+----------+-----+------+ | GPIO | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | GPIO | +------+-----+----------+------+---+ OPi 3 +---+------+----------+-----+------+ The SPI functionality is now operational, but this solution is not definitive. To address the underlying issue, I need assistance as device trees, kernels, and other aspects of Linux are not within my area of expertise. It seems that the problem with the CS pin is related to an error during the boot process, resulting in an incorrect address assignment. Well, I hope this information proves helpful to others who are experiencing the same issue as I did. Remember: English is not my first language, so there may be some errors.

Chances are, you've destroyed the integrity of the resulting DTB and the kernel can't even access the device with the rootfs. That dtso was more ment in @robertoj's direction to showcase gpio-line-names setup for this device. From the rest of your post, I don't really know what you're talking about. Nevertheless, I have written an overlay from scratch according to your recipe. For a first test, please disable any overlay application using the Armbian method in armbianEnv.txt and apply the overlay with my method. With an copy of your base DTB execute this command: fdtoverlay --input sun50i-h6-orangepi-3-lts.dtb --output sun50i-h6-orangepi-3-lts.dtb sun50i-h6-orangepi-3-lts-spi1.dtbo Now swap the currently used DTB with this one, reboot and test if it works as expected. After a successful test, you can try out the application with the Armbian method. sun50i-h6-orangepi-3-lts-spi1.dtso

I've been struggling to get interrupt to work on my 5b with a water flow sensor. Any suggestions or help is appreciated. Here's what I've tried and validated so far: Hardware: The flow sensor signal wire is connected to wiringpi pin 2, which is physical pin 7, gpio pin 54 I've put in a pull-down resistor between the gpio pin and GND I've confirmed with a multi-meter that the signal line has a voltage of 0 when the sensor isn't spinning. I've confirmed that "gpio read 2" shows the pin as 0 in that state I've confirmed that the signal line voltage peaks to around 1.5 vdc when the sensor is spinning. I've confirmed that "gpio read 2" shows the pin pulsing in that state between 1 and 0. Docker: I've exported gpio 54 and set it to in The container runs in privileged mode with volumes to all the important bits mapped Python: I wrote a stupidly simple script just to increment a counter and print its value when the interrupt is called wiringpi correctly reads and sets values for all the other gpio stuff I'm doing on the board (temp sensors and relays), it's only the interrupt job that isn't working Docs for above assertions: Python script: import wiringpi import time # The pin number to which your sensor is connected SENSOR_PIN = 2 # Initialize wiringpi wiringpi.wiringPiSetup() # Set the pin to input mode wiringpi.pinMode(SENSOR_PIN, wiringpi.GPIO.INPUT) # Initialize the counter and the tick counter = 0 def count_pulse(): global counter counter += 1 print(counter) # Set the interrupt to be triggered when the pin's voltage rises from LOW to HIGH wiringpi.wiringPiISR(SENSOR_PIN, wiringpi.GPIO.INT_EDGE_RISING, count_pulse) # To keep the script running try: while True: time.sleep(1) except (KeyboardInterrupt, SystemExit): print(f'Total pulses: {counter}') print('Exiting...') GPIO test output: Pin 2 state: 1 Pin 2 state: 1 Pin 2 state: 1 Pin 2 state: 0 Pin 2 state: 0 Pin 2 state: 0 Pin 2 state: 0 Pin 2 state: 0 Pin 2 state: 0 Pin 2 state: 0 Pin 2 state: 0 Pin 2 state: 1 Pin 2 state: 1 Pin 2 state: 1 Pin 2 state: 1 Pin 2 state: 1 Pin 2 state: 1 Pin 2 state: 1 Pin 2 state: 1 Pin 2 state: 0 Pin 2 state: 0 Pin 2 state: 0 Pin 2 state: 0 Pin 2 state: 0 Dockerfile: FROM python:3.9-slim WORKDIR /usr/src/app/squirtgun LABEL maintainer="github.com/thatsimonsguy" # Prep for downloading and installing wiringOP & wiringOP-python RUN apt-get update && apt-get install -y \ git \ gcc \ swig \ python3-dev \ python3-setuptools \ make \ sudo \ && rm -rf /var/lib/apt/lists/* # Set up wiringOP WORKDIR /usr/src/app/squirtgun RUN git clone https://github.com/orangepi-xunlong/wiringOP.git -b next WORKDIR /usr/src/app/squirtgun/wiringOP RUN ./build clean RUN ./build # Set up wiringOP-Python WORKDIR /usr/src/app/squirtgun RUN git clone --recursive https://github.com/orangepi-xunlong/wiringOP-Python -b next WORKDIR /usr/src/app/squirtgun/wiringOP-Python RUN python3 generate-bindings.py > bindings.i RUN python3 setup.py install # Export GPIO for pin 2 RUN echo 54 > /sys/class/gpio/export RUN echo "in" > /sys/class/gpio/gpio54/direction # Install app and python deps WORKDIR /usr/src/app/squirtgun COPY . . RUN pip install -r requirements.txt EXPOSE 80 ENTRYPOINT ["python", "run.py"] Docker compose: version: '3' services: squirtgun_test: image: squirtgun_test:latest privileged: true volumes: - squirtgun_config:/usr/src/app/squirtgun/config - squirtgun_db:/usr/src/app/squirtgun/db - /etc/orangepi-release:/etc/orangepi-release - /etc/armbian-release:/etc/armbian-release environment: - REGISTRATION_OTP=#### - PARENT_BASE_URL=#### - ZONE_RELAY_PINS=5 - TRANSFORMER_RELAY_PIN=7 - TEMP_SENSOR_PIN_1=8 - TEMP_SENSOR_PIN_2=9 - FLOW_SENSOR_PIN=2 - DEBUG_NO_MTLS=True ports: - "5000:5000" volumes: squirtgun_config: squirtgun_db: (I realize the port mapping between the docker compose and the dockerfile are not aligned. That's on my TODO list, but isn't a factor for this problem. I'm testing by exec'ing into the running docker container after build and executing the test script) Cheers and thanks!

Hi everyone! I didn't expect this post to be active again after almost a year without replies, so thanks for the revival! After writing this "article," I stopped investigating the problem. However, the post being active again piqued my curiosity to see if the issue was resolved. Unfortunately, the problem persists on Armbian 23.11.1 (bookworm). I tried the same steps as before, but encountered a major issue. After recompiling and compiling the dts and rebooting, my device wouldn't boot anymore. It kept showing "UUID does not exist" (and I don't know why, so if anybody knows, please tell me). I really appreciate your efforts @usual user for providing the .dts, but I think the problem lies in the overlay file of Armbian, which seems to be out of date. It seems they forgot to update the overlay, as @robertoj mentioned that this isn't a problem in the boot process; the original dts that boots on the OPi 3 LTS is correct. I followed the same steps as before: sudo armbian-config -> System -> Dtc, and in the spi@5011000 section, they updated the phandle of the pins. spi1-pins { pins = "PH4\0PH5\0PH6"; function = "spi1"; phandle = <0x32>; }; spi1-cs-pin { pins = "PH3"; function = "spi1"; phandle = <0x33>; }; But when we checked the sun50i-h6-spi-spidev1.dtbo, it remained the same. fragment@1 { target = <0xffffffff>; __overlay__ { pinctrl-names = "default"; pinctrl-0 = <0xffffffff>; status = "okay"; #address-cells = <0x01>; #size-cells = <0x00>; spidev@0 { compatible = "armbian,spi-dev"; reg = <0x00>; spi-max-frequency = <0xf4240>; }; }; }; Notice that the "pinctrl-0" is <0xffffffff>, which seems more like a placeholder than a real id of a node. The problem here is that we have a working device tree in the system, but when I activate the overlay using overlays=spi-spidev1 in /boot/armbianEnv.txt, it overwrites the correct dts and puts the wrong node id. Before adding the overlay in your boot config, you can check this by going to /sys/firmware/devicetree/base/soc/spi@5011000 and using cat on pinctrl-0: $> /sys/firmware/devicetree/base/soc/spi@5011000# cat pinctrl-0 23 What are these 2 and 3? If we look at the original device tree source, it's pinctrl-0 = <0x32 0x33>;, where 32 refers to the node spi1-pins and 33 to spi1-cs-pin. By using an ASCII to hex converter, we find that 2 corresponds to 0x32 and 3 to 0x33. You can also confirm which pins are assigned to these IDs by: $> /sys/firmware/devicetree/base/soc/pinctrl@300b000/spi1-pins# cat phandle 2 $> /sys/firmware/devicetree/base/soc/pinctrl@300b000/spi1-cs-pin# cat phandle 3 So, what happens when we add the overlay? /sys/firmware/devicetree/base/soc/spi@5011000# cat pinctrl-0 2 We see that we have 2 (MOSI.1, MISO.1, and SCLK.1) but not 3 (CE.1). In other words, we don't have CE.1 activated as WiringOP showed us. But how can I simply fix that, given that (at least to me) recompiling and compiling aren't working more? It's simple: Copy the spidev@0 part from the overlay. Access sudo armbian-config -> System -> Dtc and find spi@5011000. Put the spidev@0 inside it and set the status of this node to "okay" instead of "disabled". The final result will be: spi@5011000 { compatible = "allwinner,sun50i-h6-spi\0allwinner,sun8i-h3-spi"; reg = <0x5011000 0x1000>; interrupts = <0x00 0x0b 0x04>; clocks = <0x06 0x53 0x06 0x51>; clock-names = "ahb\0mod"; dmas = <0x2f 0x17 0x2f 0x17>; dma-names = "rx\0tx"; pinctrl-names = "default"; pinctrl-0 = <0x32 0x33>; resets = <0x06 0x20>; status = "okay"; #address-cells = <0x01>; #size-cells = <0x00>; phandle = <0x7a>; spidev@0 { compatible = "armbian,spi-dev"; reg = <0x00>; spi-max-frequency = <0xf4240>; }; }; Save the modifications and now use this command to remove the wrong overlay: $> cd /boot/dtb/allwinner/overlay/ $> mv sun50i-h6-spi-spidev1.dtbo .sun50i-h6-spi-spidev1.dtbo After the reboot, you'll see: $> ls /dev/ | grep spi spidev0.0 Using gpio readall: $> sudo gpio readall +------+-----+----------+--------+---+ OPi 3 +---+--------+----------+-----+------+ | GPIO | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | GPIO | +------+-----+----------+--------+---+----++----+---+--------+----------+-----+------+ | | | 3.3V | | | 1 || 2 | | | 5V | | | | 122 | 0 | SDA.0 | OFF | 0 | 3 || 4 | | | 5V | | | | 121 | 1 | SCL.0 | OFF | 0 | 5 || 6 | | | GND | | | | 118 | 2 | PWM.0 | OFF | 0 | 7 || 8 | 0 | OFF | PL02 | 3 | 354 | | | | GND | | | 9 || 10 | 0 | OFF | PL03 | 4 | 355 | | 120 | 5 | RXD.3 | OFF | 0 | 11 || 12 | 0 | OFF | PD18 | 6 | 114 | | 119 | 7 | TXD.3 | OFF | 0 | 13 || 14 | | | GND | | | | 362 | 8 | PL10 | OFF | 0 | 15 || 16 | 0 | OFF | PD15 | 9 | 111 | | | | 3.3V | | | 17 || 18 | 0 | OFF | PD16 | 10 | 112 | | 229 | 11 | MOSI.1 | ALT2 | 0 | 19 || 20 | | | GND | | | | 230 | 12 | MISO.1 | ALT2 | 0 | 21 || 22 | 0 | OFF | PD21 | 13 | 117 | | 228 | 14 | SCLK.1 | ALT2 | 0 | 23 || 24 | 0 | ALT2 | CE.1 | 15 | 227 | | | | GND | | | 25 || 26 | 0 | OFF | PL08 | 16 | 360 | +------+-----+----------+--------+---+----++----+---+--------+----------+-----+------+ | GPIO | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | GPIO | +------+-----+----------+--------+---+ OPi 3 +---+--------+----------+-----+------+ You should see CE.1 working. Now, use spidev-test to see if SPI is working: $> ./spidev_test -v -D /dev/spidev0.0 spi mode: 0x0 bits per word: 8 max speed: 500000 Hz (500 KHz) TX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F0 0D | ......@.... .................. . RX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F0 0D | ......@.... .................. . It's working! In the end, it seems that the overlay is incorrect (perhaps someone forgot to remove or update the "pinctrl-0 = <0xffffffff>") and needs to be updated. I don't know if the solution I created is the best way, but it's working in the recent images. If anyone has a hint to improve this solution or knows why I'm getting "UUID does not exist" when I recompile my .dtbo file, please let me know to improve my knowledge PS: You don't need to remove the overlay if you didn't add it to your armbianEnv.txt.

Hi I want to use the I2S GPIO output pins ( 26 pins ) on Orange Pi4 LTS to connect multi channel DAC. Is it possible to overlay some pins?

Out of curiosity and for my own education, I wrote the attached overlay. If you apply this to the base DTB of the orangepi 3 lts, the GPIO code of @robertoj should be able to run unchanged on this device as well. sun50i-h6-orangepi-3-lts-con1.dtso

How to wait for a button press is outlined here. If you want to be able to write code that is device-agnostic, you'll need to set up generic gpio-line-names. See here for reference. With that in place e.g.: gpiomon --num-events=1 con1-08 && my-script will be able to run on any device that has the gpio-line-names set up in the same way. I.e. will wait at pin 8 of the first extention connector for an event.

"usual user" has posted instructions to incorporate your dtbo inside the dtb... but I personally like having a separate dtbo that is applied by uboot. https://forum.armbian.com/topic/33800-orange-pi-zero-3-gpio/?do=findComment&comment=181688 dtb and dtbos are the correct way to assign pins and tell the kernel where everything is. I don't think there's anything wrong with the boot process, if it only needs a dtbo to start working correctly. Everything depends on having good dtb and dtbos.

Hello. I've searched here, the Libre computer forums, even tried "cheating" with asking chatgpt. Using a "Le Potato" AML-S905X-CC with Armbian Jammy 22.04.2 LTS. I've gotten far enough to be able to read the switch on the GPIO with pulled to 0 reading as 1. button untouched: ~$ sudo gpioget --active-low gpiochip1 97 0 button pressed: :~$ sudo gpioget --active-low gpiochip1 97 1 From here though, I can't seem to figure out what to do next. I've seen suggestions to use a python script with a sleep to using device overlays. The device overlay examples I see using armbian are typically for orange Pis and I can't seem to extrapolate to the le potato gpio, or are Libre's support saying how to do it with their custom kernels and device tree overlay tools, which I (in my foolishness? long term wisdom?) chose not to use over Armbian. If anyone has some input on what to throw at this next I'd love it. I am using this le potato as a klipper server with Fluidd and would love to be able to hit my pretty led backed power button to power down the server board and a second led lit power switch to power down the printer. In the end it's no big deal if I can't get this working, I can just shutdown the pi via Klipperscreen and then use the modified power switch on the 3d printer. But that's not as much fun as changing everything. Thank you!

Thank you for the confirmation @Vijay Gill. Here is the patch I use. I did also add the poweroff support. Splitting it into multiple files might be better, but it is good enough for my test builds. root@dumpster /m/t/t/n/build (main)# cat userpatches/kernel/rockchip-rk3588-edge/1000-arm64-dts-fix-rtc-add-poweroff-support-Orange-Pi-5-Plus.patch From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001 From: John Doe <john.doe@somewhere.on.planet> Date: Mon, 29 Jan 2024 12:51:13 +0100 Subject: Patching kernel rockchip-rk3588 files arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts Signed-off-by: John Doe <john.doe@somewhere.on.planet> --- arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts b/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts index 88bfce6237db..70cc6bd5a0af 100644 --- a/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts +++ b/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts @@ -462,11 +462,11 @@ &pcie3x4 { }; &pinctrl { hym8563 { hym8563_int: hym8563-int { - rockchip,pins = <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>; + rockchip,pins = <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_up>; }; }; leds { blue_led_pin: blue-led { @@ -572,10 +572,12 @@ pmic@0 { pinctrl-names = "default"; pinctrl-0 = <&pmic_pins>, <&rk806_dvs1_null>, <&rk806_dvs2_null>, <&rk806_dvs3_null>; spi-max-frequency = <1000000>; + system-power-controller; + vcc1-supply = <&vcc5v0_sys>; vcc2-supply = <&vcc5v0_sys>; vcc3-supply = <&vcc5v0_sys>; vcc4-supply = <&vcc5v0_sys>; vcc5-supply = <&vcc5v0_sys>; @@ -592,11 +594,11 @@ pmic@0 { gpio-controller; #gpio-cells = <2>; rk806_dvs1_null: dvs1-null-pins { - pins = "gpio_pwrctrl2"; + pins = "gpio_pwrctrl1"; function = "pin_fun0"; }; rk806_dvs2_null: dvs2-null-pins { pins = "gpio_pwrctrl2"; -- Created with Armbian build tools https://github.com/armbian/build

If anyone is looking at fixing the access for gpio and i2c - I found you can fix it with the following udev rules addgroup --system i2c addgroup --system gpio create in /etc/udev/rules.d/60-i2c-tools.rules SUBSYSTEM=="i2c-dev",KERNEL=="i2c*", GROUP="i2c", MODE="0660" create in /etc/udev/rules.d/61-gpio-tools.rules SUBSYSTEM=="gpio",KERNEL=="gpiochip*", GROUP="gpio", MODE="0660"

With armbian's DTB. cat /sys/kernel/debug/gpio root@orangepizero3:~# cat /sys/kernel/debug/gpio gpiochip0: GPIOs 0-287, parent: platform/300b000.pinctrl, 300b000.pinctrl: gpio-76 ( |red:status ) out lo gpio-77 ( |green:power ) out hi gpio-80 ( |regulator-usb1-vbus ) out hi gpio-166 ( |cd ) in lo ACTIVE LOW gpio-210 ( |reset ) out hi ACTIVE LOW gpiochip1: GPIOs 352-383, parent: platform/7022000.pinctrl, 7022000.pinctrl: root@orangepizero3:~# With the DTB you created yesterday root@orangepizero3:~# cat /sys/kernel/debug/gpio gpiochip0: GPIOs 0-287, parent: platform/300b000.pinctrl, 300b000.pinctrl: gpio-69 (con1-13 ) gpio-70 (con1-11 ) gpio-71 (con1-22 ) gpio-72 (con1-15 ) gpio-73 (con1-07 ) gpio-74 (con1-26 ) gpio-75 (con1-12 ) gpio-76 ( |red:status ) out lo gpio-77 ( |green:power ) out hi gpio-78 (con1-18 ) gpio-79 (con1-16 ) gpio-80 ( |regulator-usb1-vbus ) out hi gpio-166 ( |cd ) in lo ACTIVE LOW gpio-210 ( |reset ) out hi ACTIVE LOW gpio-226 (con1-08 ) gpio-227 (con1-10 ) gpio-228 (con1-05 ) gpio-229 (con1-03 ) gpio-230 (con1-23 ) gpio-231 (con1-19 ) gpio-232 (con1-21 ) gpio-233 (con1-24 ) gpiochip1: GPIOs 352-383, parent: platform/7022000.pinctrl, 7022000.pinctrl: root@orangepizero3:~# And, the result of gpioinfo is: And the contents of pinmux-pins

Hi, Just started playing with BananaPi (I have M2Berry model) and installed Armbian from Armbian download page: Armbian_23.5.2_Bananapim2ultra_bookworm_current_6.1.30_minimal (connecting with board over UART/SSH - no need for desktop at this moment). Wanted to use GPIO, however using sysfs do not work as expected: root@bananapim2ultra:~# echo "24" > /sys/class/gpio/export -bash: echo: write error: Unknown error 517 root@bananapim2ultra:~# echo "24" > /sys/class/gpio/export -bash: echo: write error: Device or resource busy Went with lsmod to check modules but having only: root@bananapim2ultra:~# lsmod | grep gp gpu_sched 28672 1 lima Same for modprobe: root@bananapim2ultra:~# modprobe gpio modprobe: FATAL: Module gpio not found in directory /lib/modules/6.1.30-sunxi It looks like the kernel do not have gpio module, which is really strange since the GPIO is main feature for such boards. Running armbian-config - maybe I will find something. Can somebody help me out a little with it?

I've written an overlay that I think is correct. Since I don't have a Orange Pi Zero 3 I need your help to verify my work. Therefore I have applied my overlay staticly to your provided DTB. Please replace your existing DTB with the attached one. Reboot and post the "cat /sys/kernel/debug/gpio" output again. If everything works as expected, I will post the overlay source and explain how to use it. sun50i-h618-orangepi-zero3.dtb

Good morning, I'm triying to move to armbian for tinker. Currently i'm using Debian Distro from Asus for tinkerboard and i want to move to a CLI only OS. Armbian seems to be the best option for what i want, but currently i'm unable to use the GPIO pins on the tinkerboard2. I tried to install wiringpi from here (https://github.com/TinkerBoard/gpio_lib_c/tree/sbc/tinkerboard/c) but i always recieve an error code. Anyone facing this problem? Any help will be very much appreciated, i really want to move to a non-GUI OS, but asus does't offer any option besides uninstalling X-10 GUI Thank you for your time

roberto@orangepizero3:~$ sudo cat /sys/kernel/debug/gpio gpiochip0: GPIOs 0-287, parent: platform/300b000.pinctrl, 300b000.pinctrl: gpio-76 ( |red:status ) out hi gpio-77 ( |green:power ) out hi gpio-80 ( |regulator-usb1-vbus ) out hi gpio-166 ( |cd ) in lo ACTIVE LOW gpio-210 ( |reset ) out hi ACTIVE LOW gpiochip1: GPIOs 352-383, parent: platform/7022000.pinctrl, 7022000.pinctrl: Attaching DTB from /boot/dtb/allwinner/sun50i-h618-orangepi-zero3.dtb in rolling armbian release. I dont know whether there are any armbian patches toward the GPIO, but this is the folder with armbian patches for orangepi zero 3 https://github.com/armbian/build/tree/main/patch/kernel/archive/sunxi-6.7/patches.armbian sun50i-h618-orangepi-zero3.dtb

@robertojI assumed you were looking for that pin name, number mapping for development. If so I hope that file will be helpful. If you still want the output to be in gpioinfo command, I guess you have to add the overlay as suggested by others. I personally don't use gpiod that much as I find it somewhat lacking. I last checked it in late 2022 or early 2023 I believe and it was only supporting simple gpio operations and was not supporting i2c, spi, etc. I am not sure it changed. But if its still the case and if you require to use more functionality, I will suggest going the MRAA route like I suggested before.

As allredy stated, a quite simple DTB overlay. See this thread as an entry point for discussions that have already taken place on this topic. More on gpio-line-names assignment can also be found in other posts of mine in this forum. But after the last posts in this thread I have doubts whether I should continue to participate here. IMHO the basic knowledge seems to be lacking, but they think to know exactly what the solution should look like and don't accept any other implementation. Something like this has repeatedly led to inconclusive discussions, which I am no longer prepared to engage in. If you'd like, I can try to walk you through creating a suitable overlay. For a first step, I need the output of cat /sys/kernel/debug/gpio from your running system and the DTB that is currently being used for your system. And last but not least, I need an online link to the DTB source of your device or is this already correct.

@robertoj, all, apparently, it may be possible to name the lines in the DTS https://www.kernel.org/doc/Documentation/devicetree/bindings/gpio/gpio.txt https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/gpio/gpiolib.c?h=v6.7.4#n456 Example: gpio-controller@00000000 { compatible = "foo"; reg = <0x00000000 0x1000>; gpio-controller; #gpio-cells = <2>; ngpios = <18>; gpio-reserved-ranges = <0 4>, <12 2>; gpio-line-names = "MMC-CD", "MMC-WP", "VDD eth", "RST eth", "LED R", "LED G", "LED B", "Col A", "Col B", "Col C", "Col D", "Row A", "Row B", "Row C", "Row D", "NMI button", "poweroff", "reset"; I'm not sure though if the gpio-line-names assignment can be used in pin-control devices that is currently present in the existing DTS. note also that the line/pin functions are actually defined in the source codes for the pin-control driver, just that this won't automatically appear as gpio-line-names. you may want to start experimenting, post your findings and perhaps make a PR? note that there is another source tree to commit though , which is in linux-sunxi - that would be directly mainlining / upstreaming the changes. https://linux-sunxi.org/Main_Page https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/ they have a google groups here: https://groups.google.com/g/linux-sunxi https://linux-sunxi.org/Mailing_list I'm not too sure about the procedure to commit changes in mainline though.