Search the Community

(Please ignore, this doesn't apply to the NanoPC T4) You can try if the LEDs show up after "sudo modprobe pinctrl-rk805". The switch from rockchip64 kernel 6.6.x to 6.12.x included a change that made the "pinctrl-rk805" being built as a module instead of compiled-in. That module does not get autoloaded, so it has to be added to /etc/modules. On the Klipad50, the gpio-leds are attached to the rk805 gpio bank, which is not known to the system without that kernel module. Only after loading that module, the LEDs appeared under /sys/class/leds and started working. Edit: - Board is NanoPC T4 - sorry, I haven't seen the label - The NanoPC T4 does not have the rk805 controller, so this posting does not apply. Edit#2: Do "sudo gpioset 0 13=1" or "sudo gpioset 0 13=0" change the LED state?

Below is the brightness file I found in the /sys folder. Unfortunately, I can't turn off the pwr_led light no matter what I try. I have been able to turn off the light on devices such as raspberry 3b and king3399 before, so I don't know if it is a system problem? # root @ nanopct4 in /sys [12:13:15] $ find . -name "*brightness*" ./devices/platform/gpio-leds/leds/status_led/brightness ./devices/platform/gpio-leds/leds/status_led/max_brightness ./devices/platform/fe330000.mmc/leds/mmc2::/brightness ./devices/platform/fe330000.mmc/leds/mmc2::/max_brightness

Hi, anyone have already connected a speaker to gpio of lcpi h3 v8 (like orange pi pc). I have tried but im not sure if i2s is enabled on armbian

Ryzer, Thanks a lot for your help with this. I tried a number of things and found a very simple solution that got the time down to 6 seconds. I added "gpio set 224" in the boot.cmd file and rebuilt the boot.scr file. That was it! If you happen to know any resources I could use to learn DT programming, I'm very interested in pursuing this. Thanks again, Jim

Thanks for your suggestion, Ryzer, I really appreciate you sharing your knowledge about this. To compile the new overlay, I first removed the "@0" from "leds: leds@0 {" line, to avoid a compiler warning, as AI suggested. The result is, after full boot, I now have /sys/class/leds/my_led/* interfaces and I can turn on the LED by "echo 1 > /sys/class/leds/my_led/brightness", as expected. But alas, the LED doesn't come on during the bootup sequence automatically by default. I am suspicious that perhaps some other hardware initialization is either overriding or overwriting the default-on statement in the dts file. Does it sound productive to decompile the sun7i-a20-bananapi-m1-plus.dtb file and look for references to PH0 to see if anybody else is trying to control it? The fact that the "echo 1 >" and "echo 0 >" commands turn the LED on and off appropriately, suggest to me the active-high nature of the pin must be set correctly. Would it help to apply a pull-up configuration as a default? If so, where would this go. BTW, if you could point me to a book or something I could use to learn DT programming, I'd appreciate it. Thanks again, Jim Oh, and this is interesting: AI suggested the kernel might be resetting the GPIO state during boot. It recommended creating a file named /etc/udev/rules.d/99-led-default.rules, containing one line saying, 'ACTION=="add", SUBSYSTEM=="leds", KERNEL=="my_led", ATTR{trigger}="default-on"'. This did cause the LED to now come on automatically during the boot-sequence! It turns on 21 seconds after power is applied. That's still slower than I'd hoped, but its an improvement. Does this information give you any ideas for overlay programming that could make it faster?

Hi, I'm actually working on a project with this hardware: IR + controller : https://es.aliexpress.com/item/1005005651928240.html?spm=a2g0o.order_list.order_list_main.5.21a9194dT8Becw&gatewayAdapt=glo2esp MPR121: https://es.aliexpress.com/item/1005005097989944.html?spm=a2g0o.order_list.order_list_main.11.21a9194dT8Becw&gatewayAdapt=glo2esp Bluetooth speaker, but i would use the chip that comes with orange pi . My answer is that i have all of these working inside a raspberrie pi 3 b 1.2, with python to detect the mpr121 pulsations and ir pulsations and manage connection Bluetooth, my problem is that I want to be sure that works, and actually the orange pi zero 2w its soo good cause comes already with antenna, so good, cause my project going to be Bluetooth intensive, its more powerful, comes with usb-c, its perfect for what i need, but my main problem is that there's soooo difficult to find any guides about gpio config, or test with devices like the ir or mpr121, so It's possible to make this setup with the orange py zero 2, if it, there's somewhere with an extense guide on how to use it, or at least someone that know's it (I can pay for the help). Thank you very much. Apologies for my English....

Hi, Armbian_21.02.3_Odroidc1_focal_current_5.10.21 how do I find out which number do I need to provide to gpio export command? Let's say I have physical pin 16, which is labeled by the manufacturer as `GPIOX.5` or `102`. But that doesn't work with Armbian: echo 102 > /sys/class/gpio/export [ 1602.030617] export_store: invalid GPIO 102 How do I know the value to provide for /sys/class/gpio/export? # cat /sys/kernel/debug/gpio gpiochip1: GPIOs 413-428, parent: platform/c8100084.pinctrl, aobus-banks: gpio-416 ( |TF_IO ) out lo gpio-417 ( |usb-hub-reset ) out hi gpio-426 ( |c1:blue:alive ) out hi ACTIVE LOW gpiochip0: GPIOs 429-511, parent: platform/c1109880.pinctrl, cbus-banks: gpio-456 ( |regulator-tflash_vdd) out lo gpio-470 ( |PHY reset ) out hi ACTIVE LOW gpio-482 ( |cd ) in hi ACTIVE LOW gpio-492 ( |reset ) out hi ACTIVE LOW Thanks

Hi jimw, You are currently addressing the pin controller twice as it performs both pin control and gpio control operations. Try something like this which should work. The led node should make it visible in '/sys/class/leds' /dts-v1/; /plugin/; /{ compatible = "allwinner,sun7i-a20"; fragment@0 { target = <&pio>; __overlay__{ my_led_pin: my_led_pin { pins ="PH0"; function = "gpio_out"; }; }; }; fragment@1 { target-path = "/"; __overlay__ { leds: leds@0 { compatible = "gpio-leds"; pinctrl-names = "default"; pinctrl-0 = <&my_led_pin>; status = "okay"; led: led { label = "my_led"; gpios = <&pio 7 0 0>; default-on; }; }; }; }; }; note the pinctrl control reference '&pio' always take 3 arguments the first is the number of the port which starts with A=0 and goes to I=8. The second is the pin on that particular port and finally the pin state which can either be active high = 0 or active low = 1.

Hello Armbian Team, i have the wish for the integration of - GPIO Support for RockPi 5b to the Edge Kerne - dtb's which are aviable for Kernel 5.10.160 mostly importend for me are the UARTS ( if tryed to compile the DTS files form 5.10.160 for the 6.8.2 .. ends after sending some to the UART with a Kernel segfault 😞 ) Thanks a lot for the good Work 🙂 René

There are multiple lines starting with overlay= Put all in one line like overlays=uart1 uart2 uart3 uart4 i2s i2c whatever Make sure the enabled overlays don't share same GPIO pins. Check your boards datasheet/manual.

I have Armbian up and running on a Rock Pi S with a PoE HAT. To enable the audio jack on the PoE HAT I had to run the following commands as mentioned on the official Rock Pi S PoE Hat wiki. # echo 15 > /sys/class/gpio/export # echo out > /sys/class/gpio/gpio15/direction # echo 1 > /sys/class/gpio/gpio15/value Once enabled, the audio works as needed. However, every time the device is rebooted I have to SSH in and run these commands again to re-enable audio out which is obviously not ideal. How can I persist these changes between reboots?

Armbian Version BOARD=bananapif3 BOARD_NAME="BananaPi BPI-F3" BOARDFAMILY=spacemit BUILD_REPOSITORY_URL=https://github.com/armbian/build BUILD_REPOSITORY_COMMIT=2f1fa5f40 LINUXFAMILY=spacemit ARCH=riscv BOOT_SOC= IMAGE_TYPE=nightly BOARD_TYPE=csc INITRD_ARCH=riscv KERNEL_IMAGE_TYPE=Image KERNEL_TARGET=current KERNEL_TEST_TARGET= FORCE_BOOTSCRIPT_UPDATE= FORCE_UBOOT_UPDATE= OVERLAY_DIR="" VENDOR="Armbian" VENDORDOCS="https://docs.armbian.com" VENDORURL="https://www.armbian.com/" VENDORSUPPORT="https://forum.armbian.com" VENDORBUGS="https://www.armbian.com/bugs" VERSION=25.5.0-trunk.52 REVISION=25.5.0-trunk.52 BRANCH=current I tried to enbale the I2C bus according followig documentation - but it didn't work for me. https://forum.banana-pi.org/t/bananapif3-gpio-wiringpi-gpiod-python3-periphery-adafruit-blinka-and-luma-examples/18948 https://paste.armbian.de/furuzimipu [ 0.535367] /soc/i2c@d401d800/spm8821@41: Fixed dependency cycle(s) with /soc/i2c@d401d800/spm8821@41/regulators/DCDC_REG5 [ 0.558741] raid6: int64x8 gen() 1179 MB/s [ 0.559346] spacemit-regulator spacemit-regulator@spm8821: DMA mask not set [ 0.599031] /soc/i2c@d401d800/spm8821@41: Fixed dependency cycle(s) with /soc/i2c@d401d800/spm8821@41/regulators

I would say, and I bet @Jean-Francois Lessard agrees, that is not a matter of "messing with my code" thing, but rather a matter of principles. A kernel module is supposed to do a kernel module or, In simple words, it interfaces the kernel with the hardware. The kernel means are to give the userspace a way to access the hardware. The module should not run any user business (eg: display something user-specific at boot/shutdown/whatever), but should in turn provide a service for the userspace to control the hardware. That's a simple principle in software engineering that's called "separation of responsibility", and is generally considered a good habit to agree with that principle. By the way, if your board has one or more colored leds, they are generally set up in the device tree and access basic GPIO system, so they are turned on as soon as the kernel starts.

I have currently this on SD-card: root@rock3a:~# ls -1 /boot/vmlinuz-* /boot/vmlinuz-5.10.160-39-rk356x /boot/vmlinuz-6.12.12-current-rockchip64 /boot/vmlinuz-6.13.1-edge-rockchip64 /boot/vmlinuz-6.1.99-vendor-rk35xx Only with the 5.10 kernel from Radxa, I get both NVMe and SATA when I use the overlay 'rock-3a-sata.dtbo'. With 6.12 and 6.13, there is only SATA, no NVMe. 6.1 lets the kernel/board crash, I have not further looked into that. So I can reliably use the SATA HDD, also hd-idle spindown works, I monitor the powerconsumption per day on 12V level and it is great. So as a slow clone/backup NAS it works and is acceptable. But ultimate plan is to make it a fast/main NAS, using the NVMe as cache and also for OS, so only SPI+NVMe+SATA. 5.10 kernel lacks various Btrfs features, so that is a no-go. I need at least 6.1, although I know weird virtualization tricks to get it to work on a functional level, but then also, I might hit issues with KVM on the Radxa rk356x kernel. I got the kernel from: https://radxa-repo.github.io/bookworm/files.list Regarding power, I now use 12V as base (common GND), feed 12V into the Rock3A USB-C connector and 3.5inch 12V pin on HDD and tap 5V from Rock3A GPIO and that feeds the 5V pin of the HDD. As said, that works very nice and stable. So it still looks like the 'rock-3a-sata.dtbo' overlay 'hides/disables all PCIe', where it should not do anything with the PCIe3x2 where the NVMe is on. I saw this: https://patchwork.kernel.org/project/linux-rockchip/patch/20250106100001.1344418-2-amadeus@jmu.edu.cn/ but not sure if it is related.

Hmm the plot thickens dmesg | grep Open - gives me this - so it's not finding the vfd.conf file and is looking in the Device Tree for instructions as a fallback - so where does this vfd.conf file go? [ 14.228662] OpenVFD: Version: V1.4.4 [ 14.228681] OpenVFD: vfd_gpio_clk: Empty. [ 14.228686] OpenVFD: vfd_gpio_dat: Empty. [ 14.228691] OpenVFD: vfd_gpio_stb: Empty. [ 14.228698] OpenVFD: vfd_gpio0: #0 = 0x00; #1 = 0x00; #2 = 0xFF; [ 14.228704] OpenVFD: vfd_gpio1: #0 = 0x00; #1 = 0x00; #2 = 0xFF; [ 14.228711] OpenVFD: vfd_gpio2: #0 = 0x00; #1 = 0x00; #2 = 0xFF; [ 14.228718] OpenVFD: vfd_gpio3: #0 = 0x00; #1 = 0x00; #2 = 0xFF; [ 14.228724] OpenVFD: vfd_gpio_protocol: #0 = 0x00; #1 = 0x00; [ 14.228728] OpenVFD: vfd_chars: Empty. [ 14.228733] OpenVFD: vfd_dot_bits: Empty. [ 14.228738] OpenVFD: vfd_display_type: Empty. [ 14.228749] OpenVFD: Detected gpio chips: 300b000.pinctrl, 7022000.pinctrl. [ 14.228753] OpenVFD: Failed to verify VFD configuration file, attempt using device tree as fallback. [ 14.237971] OpenVFD: openvfd_gpio_clk: pin = 267, flags = 0x00 [ 14.237998] OpenVFD: openvfd_gpio_dat: pin = 268, flags = 0x00 [ 14.238004] OpenVFD: openvfd_gpio_stb pin entry not found [ 14.238009] OpenVFD: openvfd_gpio0 pin entry not found [ 14.238013] OpenVFD: openvfd_gpio1 pin entry not found [ 14.238017] OpenVFD: openvfd_gpio2 pin entry not found [ 14.238021] OpenVFD: openvfd_gpio3 pin entry not found [ 14.238025] OpenVFD: chars_prop = 00000000a90cb56d [ 14.238033] OpenVFD: chars_prop->length = 5 [ 14.238036] OpenVFD: char #0: 2 [ 14.238040] OpenVFD: char #1: 1 [ 14.238044] OpenVFD: char #2: 2 [ 14.238048] OpenVFD: char #3: 3 [ 14.238052] OpenVFD: char #4: 4 [ 14.238057] OpenVFD: dot_bits_prop = 000000008d579c57 [ 14.238061] OpenVFD: dot_bits_prop->length = 7 [ 14.238065] OpenVFD: dot_bit #0: 0 [ 14.238070] OpenVFD: dot_bit #1: 1 [ 14.238073] OpenVFD: dot_bit #2: 3 [ 14.238077] OpenVFD: dot_bit #3: 2 [ 14.238081] OpenVFD: dot_bit #4: 4 [ 14.238085] OpenVFD: dot_bit #5: 5 [ 14.238089] OpenVFD: dot_bit #6: 6 [ 14.238094] OpenVFD: display.type = 0, display.controller = 3, pdata->dev->dtb_active.display.flags = 0x00 [ 14.238531] OpenVFD: Select FD650 controller [ 14.238612] OpenVFD: SW I2C interface intialized (address = 0x0000 (N/A), MSB mode, pull-ups off)

Dear Community, Currently Im playin with my Banana Pi M2 Berry and therefore I need a fusion of the LATEST Armbian -System with the compilers needed by the Boards Offical "GPIO-Libarys", which are outdated 7years ago. The most important libary would be the RPi.GPIO. RPi.GPIO The problem is, that this libary was using python2 and python3, python2 isnt my future i think, but for compiling the lib with python3 I need some pip-packages and the right arm-gcc compiler = 4.8 i think. DO i may need a cross-compile libary or whats are the requirements to build the lib on the latest system? To avoid hardware-determiner ERRORS, Im using the folder and its scripts/configs used in the offical Raspbian build for this device. The goal: The Latest Armbian-build with re-supported libarys like rpi.gpio or wiringpi! If there is someone who would like to update the GPIO-Controlling Libarys for Banana Pi with me, i'd be gratefull if some people let me know by pn, e-mail or github! Thanks, BlackLeakz

Hello everyone, This is my 1st post on the forum. My intention with this post is not to report a specific issue that I am running into, but more because I would like to collect info and suggestions from people with more experience than myself. I've recently received an Orange Pi 5 Plus and have spent a bit of time exploring operating systems suitable for this system and have settled on the Armbian solution. I'm a HW designer by trade, and have done some SW work, but I do not consider myself proficient in SW at all. I find my way around things, but that's about as far as it goes.... For the my planned use of the OPi5+, I will need eMMC boot (for the improved OS performance and longevity) and access to the various interfaces (mainly SPI and I2C) on the GPIO header. What I have discovered so far: - Version 6.1 of the Armbian built kernel supports the GPIO interfaces quite well (I haven't actually communicated with anything yet, just got the interfaces showing up in /dev), but I could not get it to see the eMMC storage on the board. I tried various different options and flavours of the 6.1 images and I never saw /dev mmcblk0 listed. - Version 6.10 kernel builds were successful at accessing the eMMC (/dev/mmcblk0 was present) and I have successfully transferred the OS to the eMMC storage on the board. However this version of the kernel has a limited number of device tree overlays (mostly different UART options, and one I2C option). I'm assuming that the 6.10 kernel is quite a new build and that more support for the board's IO should be available soon. Did I overlook something on the 6.1 version regarding the eMMC support? Am I missing something regarding overlays in the 6.10 build? My thinking is to stay with 6.10 as it supports eMMC and it's the newest kernel version. Cheers Volt

@Jean-Francois Lessard You won't believe it, but I found my error(s) .... For the solution I had to look at the dts Paolo (https://github.com/paolosabatino/leds-fd6551) suggested in his code. I missed a line that effectively makes SDA really open-drain. However, pinctrl is not relevant in this context. The fist line is bloody important, the second not so: i2c-gpio,sda-output-only; i2c-gpio,scl-output-only; Although they do incur warnings in the kernel log, they are indispensable because without them, i2c signals don't reach the fd6551 controller. Now everything works as expected. It shows (in fact, it showed ...) 88:88 right at the start and after that the actual time. Great! I'm going to write a pull request for Nicolas' Github repo so that he can integrate it with the Armbian distribution. I also edited your tm16xx source code to show 'boot' instead of 88:88, which is not my cup of tea. You also have to make sure you compile the driver als built-in and not as a kernel object. So you get the 'boot' writing roughly around second 2.8 in the boot process when plugging in the mains adapter and this is early enough for me. I attach all of the sources to this post. I hope you don't mind too much that I messed with your code and I apologize upfront. Best wishes, Deetsh tm16xx_boot.c display-client-snippet.dts

NB - evtest does not come with Armbian Bookworm. A quick "apt install evtest" and we're away! root@radxa-e20c:~# evtest /dev/input/event0 Input driver version is 1.0.1 Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x100 Input device name: "gpio-keys" Supported events: Event type 0 (EV_SYN) Event type 1 (EV_KEY) Event code 185 (KEY_F15) Key repeat handling: Repeat type 20 (EV_REP) Repeat code 0 (REP_DELAY) Value 250 Repeat code 1 (REP_PERIOD) Value 33 Properties: Testing ... (interrupt to exit) Event: time 1739040710.916095, type 1 (EV_KEY), code 185 (KEY_F15), value 1 Event: time 1739040710.916095, -------------- SYN_REPORT ------------ Event: time 1739040711.050330, type 1 (EV_KEY), code 185 (KEY_F15), value 0 Event: time 1739040711.050330, -------------- SYN_REPORT ------------ Do you know where I can find information on how to change settings for this button?

You can use "evtest /dev/input/event0" to analyze its output. Docs for gpio-leds: https://www.kernel.org/doc/Documentation/devicetree/bindings/leds/common.yaml https://www.kernel.org/doc/Documentation/devicetree/bindings/leds/leds-gpio.txt

TY for your reply. They definitely can be controlled by echoing values to the `/sys/class/leds/` and even though the "trigger" is set to "netdev" and tx and rx files appear, I'm not seeing any activity on those LEDs with network activity. I can manually make the LEDs blink by doing something like echo heartbeat > /sys/class/leds/lan-led/trigger cat /sys/class/leds/lan-led/trigger will show the available triggers, and a [] around the currently selected one. cat trigger none usb-gadget usb-host rc-feedback bluetooth-power rfkill-any rfkill-none kbd-scrolllock kbd-numlock kbd-capslock kbd-kanalock kbd-shiftlock kbd-altgrlock kbd-ctrllock kbd-altlock kbd-shiftllock kbd-shiftrlock kbd-ctrlllock kbd-ctrlrlock mmc0 timer oneshot disk-activity disk-read disk-write ide-disk mtd nand-disk heartbeat backlight gpio cpu cpu0 cpu1 cpu2 cpu3 activity default-on transient flash torch panic [netdev] mmc1 It looks very configurable, just doesn't seem to be "automatically" working to show network activity.

@Meestor_X From what I can see in the schematic for the E20C, the Ethernet LEDs are wired directly to the Ethernet controller chip. Can not be accessed by the SoC/OS via GPIO, therefore there is nothing you can do to control their behavior. However I would think that it should just work out of the box, so there is nothing you need to do either. If it doesn't work then I dunno, ask Radxa or something

Hello I'm running the NAS on Orange PI 5. I've run Armbian with EDK2 from https://github.com/armbian/build/pull/5900. The system starts from SSD disk connected via PCIE card with 4 SATA ports. I wanted to run simple fan control via GPIO, but setting the value 1 or 0 on GPIO has no effect and the multimeter connected to GPIO always shows 2.85V. How I did it. I installed wiringOP as the manual says. I selected GPIO 0 and entered the commands gpio mode 0 out gpio write 0 0 I connected a multimeter to GPIO 0 but it always shows 2.85V when I did gpio write 0 1 the multimeter also shows 2.85V gpio readall shows 1 in column V when "gpio write 0 1" command is shows 0 in column V when "gpio write 0 0" command is Does anyone have an idea what I'm doing wrong?

@Jean-Francois Lessard Thanks for your comprehensive answers. They helped me a lot, but as ill luck would have it, new questions arose ... As far as I can tell, the driver is loaded at second 2.7, which is perfectly early enough for me. Once the driver is ready to operate 8888 should be visible. Well, should .. I managed to get it running once and then I changed the config or the board dts or whatever and I never reached this state again, what a sh*t! May be you can spot any error in the dts, but I have the feeling that the error lurks somewhere else. You are so right, one can comment accurately on my questions if there is no dts you can look at. This time I attach my full dts to this post, promised. BTW, like I said before, I have an H96 Max V56, which has an FD6551 on the board. So there is no confusion. Rest assured, brightness is behaving as expected but is waaay to dark for me. If only those leds had white color ... Well I have made the led display "brighter" in a rather unconventional way -> I used a saw and sawed out a little rectangle from the front. Maybe my tv box doesn't look as pleasing as before, but the led display is much brighter now. Form follows function , ya know?! 🤣 Since the led display did work once, I think both SDA and SCL are configured correctly. i2c-6 is, in fact, the i2c node the kernel assigned to the tm16xx driver. When my tv box starts, somewhere in the kernel log I get i2c-gpio display-client: using lines 12 (SDA) and 11 (SCL) ... tm16xx 6-0024: Failed to set brightness: -6 tm16xx 6-0024: Failed to initialize display: -6 (-6 is ENXIO -> no device) The driver simply is unable to talk to the chip and I really don't know why. BTW my kernel has version 6.12.12 and the tm16xx is not built in but is a .ko Understood, I tried them and they worked, but thanks for the explanation (I found them earlier on your Github pages.) Yep, later. Led display isn't working right now ... 🙂 I have the feeling that using pinctrl would necessitate a "slight" rewrite of your driver and at the moment my inclination to go down this rabbit hole is, well, limited... But the question is,if there is a pinctrl definition regarding these two GPIO lines, will this definition interfere with the definition of the gpio lines in the display-client section? When using pinctrl I couldn't find any way to set the baud rate used for the communication. Is it unnecessary or is there some sort of auto-negotiation? So if you have any idea how I can arrive at a working led display again, please(!) let me know. Currently I'm at my wits end. All the best, Deetsh P.S.: oh, there is one thing I need to ask you: Do you know a way to make testing new versions of the dts easier than building an image and downloading in the emmc? myboard.dts

Hello, this is weird. With armbian 23.8.1 I can access the gpio-pins of the raspberry 4b. With (current) armbian 24.2.1 neither wiringpi (gpio -v) works nor any direct access (like echo "4" > /sys/class/gpio/export) The only difference I can find is the version of armbian. Please give me a hint on how to get gpio-access working with the current armbian. THX Edit: with raspbian it works (echo "4" > /sys/class/gpio/export and cat /sys/class/gpio/gpio4/value), so apparently I used the correct method.