Search the Community

Hi! I need to make sure that my GPIOs remember the last state when my Tinkerboard reboots. Is it possible to modify the bootloader and avoid GPIO.cleanup? If yes, then how? Thanks!

unable to access gpio using wiringpi python. I have tried steps available on banana pi wiki. but it throws error "/dev/gpiomem" is not available and then "This board is not odroid". did anyone successfully implemented this?

Read what the original author posted. Banana Pi CM4 has full generic GPIO support in mainline kernel ready to use. With libgpiod, all the necessary Python 3 bindings are available, so start writing your planned application. Since you have even developed the board yourself, you also have the necessary knowledge of which of the approximately 100 GPIO-capable pins you have wired where.

I wanted to share 2 custom overlays I've created and tested for the RockPi E to enable UART1 and OTG via the GPIO. Create file rockchip-uart1.dts /dts-v1/; / { compatible = "rockchip,rk3328"; fragment@0 { target-path = "/serial@ff120000"; __overlay__ { pinctrl-0 = < 0x23 >; status = "okay"; }; }; }; Create file rockchip-otg.dts /dts-v1/; / { compatible = "rockchip,rk3328"; fragment@0 { target-path = "/usb@ff580000"; __overlay__ { dr_mode = "otg"; }; }; }; Install and enable overlays: sudo armbian-add-overlay rockchip-uart1.dts sudo armbian-add-overlay rockchip-otg.dts

Thanks for the response guys. and let me tell you the exact reason why I am seeking help for Wiring pi. So basically we have developed baseboard for banana pi cm4 which has on board: WS2812B LEDs Real-time clock (RTC) RF transceiver IR transceiver XBee module SD card slot MPU6030 motion sensor. WiringPi's extensive Python libraries offer a convenient way to interact with these peripherals. While Raspberry Pi/Other supported board enjoys mature GPIO (support through WiringPi, similar functionality remains limited for Banana Pi CM4. I am Seeking Guidance, Not a Complete Solution, Let me clarifies my objective: My aim to gain knowledge and navigate the process independently. Sharing my findings and experiences with the community is intended. I welcome any insights or alternative solutions that the community might possess. I appreciate the previous responses and support. Again I require assistance in utilizing WiringPi for Banana Pi CM4. Limited GPIO support on Banana Pi CM4 hinders the direct use of WiringPi. I am seeking guidance and knowledge to overcome this obstacle. Thank you again.

Hello! I am looking to set up edge monitoring for both rising and falling edges. I can monitor either individually but I cannot activate both edges. I receive: genirq: setting trigger mode 3 for irq 36 failed (meson_gpio_irq_set_type+0x0/0x60) I have attempted to use mraa-gpio, gpiod, and sysfs all with the same result. I'm on a Radxa Zero running Armbian 23.5 Jammy (Kernel 6.1.y). Interestingly if I attempt to run Manjaro on this board I can interface with the pins to get the values and set direction but I have no edge detection. Is the GPIO driver in Armbian patched for Amlogic Meson G12A? Hoping I'm posting in the right place! I may cross-post to be sure. Thanks!

Hi! I try to use GPIO on BananaPi M5 board. But interface doesn't work. Armbian 23.05.1 Jammy with Linux 6.1.30-meson64. /boot/armbianEnv.txt: verbosity=1 console=both overlay_prefix=meson fdtfile=amlogic/meson-sm1-bananapi-m5.dtb rootdev=UUID=d099eb25-cf52-43fb-b826-535b9109637f rootfstype=ext4 overlays=w1-gpio usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u m5@bananapim5:~$ dmesg | grep w1 [ 7.568386] w1-gpio onewire@0: gpio_request (pin) failed [ 7.607814] w1-gpio onewire@0: gpio_request (pin) failed [ 7.620109] w1-gpio onewire@0: gpio_request (pin) failed [ 7.662444] w1-gpio onewire@0: gpio_request (pin) failed [ 7.671512] w1-gpio onewire@0: gpio_request (pin) failed [ 7.677156] w1-gpio onewire@0: gpio_request (pin) failed [ 7.689428] w1-gpio onewire@0: gpio_request (pin) failed [ 7.693341] w1-gpio onewire@0: gpio_request (pin) failed [ 7.711606] w1-gpio onewire@0: gpio_request (pin) failed [ 7.714019] w1-gpio onewire@0: gpio_request (pin) failed [ 7.784669] w1-gpio onewire@0: gpio_request (pin) failed [ 7.836363] w1-gpio onewire@0: gpio_request (pin) failed [ 7.877654] w1-gpio onewire@0: gpio_request (pin) failed [ 7.915447] w1-gpio onewire@0: gpio_request (pin) failed [ 7.975862] w1-gpio onewire@0: gpio_request (pin) failed [ 7.983126] w1-gpio onewire@0: gpio_request (pin) failed [ 18.143361] w1-gpio onewire@0: gpio_request (pin) failed Have any ideas?

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

Hello everyone! I was struggling to make wiring work on OrangePi 5 Plus armbian. Tried everything and came up with a solution that worked for me. I was constantly getting these errors: wiringPiSetup: mmap (PWM) failed: Operation not permitted wiringPiSetup: mmap (GPIO) failed: Operation not permitted I'm on 23.8.2. 1. Install armbian and update apt sudo apt update 2. As stated in OrangePi5Plus wiki page I got .deb installer for wiringPi on OrangePi Now here's the link to this file: https://github.com/orangepi-xunlong/orangepi-build/blob/next/external/cache/debs/arm64/wiringpi_2.51.deb 3. The most important step was described here: https://github.com/Joshua-Riek/ubuntu-rockchip/issues/273 echo "BOARD=orangepi5plus" | sudo tee /etc/orangepi-release Somehow this solves the issue. No idea how these things work tbh... 4. Check if pins are detected via gpio readall or add sudo sudo gpio readall You should get a table with all the pins and numbers like this: 5. Install wiringop-python just as stated in the manual: http://www.orangepi.org/orangepiwiki/index.php/Orange_Pi_5_Plus#How_to_install_wiringOP-Python # get the dependencies sudo apt-get update sudo apt-get -y install git swig python3-dev python3-setuptools # clone wiringOP-python repo, the branch should be "next" and NOT "main" or "master" git clone --recursive https://github.com/orangepi-xunlong/wiringOP-Python -b next cd wiringOP-Python git submodule update --init --remote python3 generate-bindings.py > bindings.i sudo python3 setup.py install The wiringOP-Python should be working now.

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?

Thank you for your answer. Sorry, I didn't write this, but GPIO is sterring the fan through a transistor. I will check it on a newer version of the distribution, the one I have is the beta version. Maybe that's the problem.

you can't use GPIO as power supply for fan, this will break the gpio bank. you can use GPIO as ON/OFF switch for fan, you should use "gpio-fan" driver. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Documentation/devicetree/bindings/hwmon/gpio-fan.txt?h=v6.7.8 by this you can use /sys/class/thermal/cooling_deviceX/state control you fan, but if you want to system automatically enable your fan at certan temperature, you need register the fan as a cooling device, for cpu/gpu or hard driver. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml

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!

Hello, I would like to ask you something. Preliminary remark: I am not experiencing any particular malfunctions at the moment. Launching the command 'dmesg | grep mmc' I notice some errors at the end of the log: [ 2.503983] dwmmc_rockchip ff500000.mmc: IDMAC supports 32-bit address mode. [ 2.504032] dwmmc_rockchip ff500000.mmc: Using internal DMA controller. [ 2.504053] dwmmc_rockchip ff500000.mmc: Version ID is 270a [ 2.504148] dwmmc_rockchip ff500000.mmc: DW MMC controller at irq 39,32 bit host data width,256 deep fifo [ 2.504182] dwmmc_rockchip ff510000.mmc: IDMAC supports 32-bit address mode. [ 2.504224] dwmmc_rockchip ff510000.mmc: Using internal DMA controller. [ 2.504243] dwmmc_rockchip ff510000.mmc: Version ID is 270a [ 2.504328] dwmmc_rockchip ff510000.mmc: DW MMC controller at irq 40,32 bit host data width,256 deep fifo [ 2.504705] dwmmc_rockchip ff500000.mmc: Got CD GPIO [ 2.504748] dwmmc_rockchip ff510000.mmc: allocated mmc-pwrseq [ 2.504768] mmc_host mmc1: card is non-removable. [ 2.505873] dwmmc_rockchip ff520000.mmc: IDMAC supports 32-bit address mode. [ 2.505932] dwmmc_rockchip ff520000.mmc: Using internal DMA controller. [ 2.505953] dwmmc_rockchip ff520000.mmc: Version ID is 270a [ 2.506046] dwmmc_rockchip ff520000.mmc: DW MMC controller at irq 41,32 bit host data width,256 deep fifo [ 2.506584] dwmmc_rockchip ff5f0000.dwmmc: IDMAC supports 32-bit address mode. [ 2.506657] dwmmc_rockchip ff5f0000.dwmmc: Using internal DMA controller. [ 2.506679] dwmmc_rockchip ff5f0000.dwmmc: Version ID is 270a [ 2.506784] dwmmc_rockchip ff5f0000.dwmmc: DW MMC controller at irq 42,32 bit host data width,256 deep fifo [ 2.507066] mmc_host mmc2: card is non-removable. [ 2.507330] dwmmc_rockchip ff5f0000.dwmmc: Got CD GPIO [ 2.517666] mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0) [ 2.517738] mmc_host mmc0: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0) [ 2.518163] mmc_host mmc3: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0) [ 2.518260] mmc_host mmc2: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0) [ 2.664219] mmc_host mmc1: Bus speed (slot 0) = 100000000Hz (slot req 100000000Hz, actual 100000000HZ div = 0) [ 2.919494] mmc_host mmc2: Bus speed (slot 0) = 50000000Hz (slot req 52000000Hz, actual 50000000HZ div = 0) [ 2.919602] mmc_host mmc2: Bus speed (slot 0) = 150000000Hz (slot req 150000000Hz, actual 150000000HZ div = 0) [ 3.142700] dwmmc_rockchip ff510000.mmc: Successfully tuned phase to 155 [ 3.146775] mmc1: new ultra high speed SDR50 SDIO card at address 0001 [ 3.202282] dwmmc_rockchip ff520000.mmc: Successfully tuned phase to 145 [ 3.203725] mmc2: new HS200 MMC card at address 0001 [ 3.210480] mmcblk2: mmc2:0001 DF4064 58.2 GiB [ 3.217802] mmcblk2: p1 [ 3.221230] mmcblk2boot0: mmc2:0001 DF4064 4.00 MiB [ 3.228213] mmcblk2boot1: mmc2:0001 DF4064 4.00 MiB [ 3.235001] mmcblk2rpmb: mmc2:0001 DF4064 4.00 MiB, chardev (242:0) [ 4.407228] EXT4-fs (mmcblk2p1): mounted filesystem with writeback data mode. Quota mode: none. [ 6.724310] EXT4-fs (mmcblk2p1): re-mounted. Quota mode: none. [ 8.973626] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac4334-sdio.rockchip,rk3318-box.bin failed with error -2 [ 8.980814] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac4334-sdio.clm_blob failed with error -2 while when I launch "dmesg | grep error" I see this log: [ 8.870879] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2 [ 8.973626] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac4334-sdio.rockchip,rk3318-box.bin failed with error -2 [ 8.980814] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac4334-sdio.clm_blob failed with error -2 What can this indicate? Are these 'normal' errors? Thank you

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?

@svdmk ok so that gpio-poweroff is a leftover or some copy/paste from another board done by the manufacturer. The more I read the more I think it is related with the trust os: when you leave the first 8192 sectors from armbian 21.02.1 on the eMMC, you actually leave all the boot pieces there. The boot process is made of 4 pieces: ddrbin, u-boot SPL, Trust Os and u-boot. Rockchip devices always boot from eMMC first, so whatever you put in the sdcard, the boot process always happens in the eMMC, then u-boot steers to the sdcard. My best guess for your problem is that armbian 21.02.1 bootloader still had OPTEE opensource Trust OS I was using in the past (see here for source code); it is the same base that also rockchip uses for its Trust OS, but rockchip proprietary trust os has some closed-source code that is added on top for added features like DDR clock scaling and virtual poweroff and who knows what else... Nowadays I use the rockchip proprietary optee for those added features, but very seldom it causes issues like yours and it is impossible to debug because it is closed source. What you can do in the meantime, hoping it works install armbian 24.02 on the emmc via multitool using the regular burn to image function then get a shell and do a dd to copy the bootloader from armbian 21.02.1 image over the 24.02 u-boot and Trust Os are "packaged together". The package starts at sector 0x200 AFAIR and is around one megabyte large, but I suggest to you to copy all the bootloader that starts at 0x20 A command like this would do the trick: (of course change armbian21.img with the actual image) dd if=armbian21.img of=/dev/mmcblk2 skip=32 seek=32 count=8160 sync Or, if you have the .xz compressed image: xz -c -d -k armbian21.img.xz | dd of=/dev/mmcblk2 skip=32 seek=32 count=8160 sync Then you should be able to boot multitool, libreelec and armbian from sdcard and also armbian should boot from eMMC without issues. I will have some confrontation with @fabiobassa and @ilmich to see if there is a viable general solution.

I'm trying to get a HDMI LCD touchscreen working. The pinout is compatible with Orange PI PC except the SPI CS pin is on pin 26 (WPI 11) instead of pin 24 (WPI 10). Is there an easy way to move the SPI CS pin to another GPIO pin? Also, I'm not sure how to properly configure the pen down interrupt pin for pin 22 (WPI 6) So far, I've got the following working: Image: Orangepipc_2.0.8_debian_buster_desktop_linux5.4.65.7z Touchscreen: 3.5 Inch HD HDMI USB LCD Touch Screen 3.5" Display Module 480×320 1920x1080 for Raspberry Pi 3rd 4th Generation 4B/3B+/3B/2B orangepiEnv.txt: overlays=spi-add-cs1 spi-spidev param_spidev_spi_bus=0 param_spidev_spi_cs=0 Luckily, the kernel headers are loaded, so Makefile works. mkdir ds7846 cd ds7846 wget https://sourceforge.net/p/openipmi/linux-ipmi/ci/master/tree/drivers/input/touchscreen/ads7846.c?format=raw mv ads7846.c?format=raw ads7846.c nano Makefile: obj-m := ads7846.o KDIR := /lib/modules/$(shell uname -r)/build PWD := $(shell pwd) all: $(MAKE) -C $(KDIR) M=$(PWD) modules clean: $(MAKE) -C $(KDIR) M=$(PWD) clean install: $(MAKE) -C $(KDIR) M=$(PWD) modules_install make make install depmod cd .. git clone https://github.com/notro/fbtft_tools/ cd fbtft_tools/ads7846_device make make install depmod cd .. sudo nano /etc/modules-load.d/99-ads7846.conf ads7846 ads7846_device sudo nano /etc/modprobe.d/ads7846_device.conf options ads7846_device model=7846 verbose=2 cs=0 gpio_pendown=1 keep_vref_on=1 swap_xy=1 pressure_max=255 x_plate_ohms=60 x_min=200 x_max=3900 y_min=200 y_max=3900 after reboot, the SPI device is there and the touch driver attaches to the port. [ 7.124454] ads7846_device: loading out-of-tree module taints kernel. [ 7.125336] ads7846_device: ads7846_device_init() [ 7.125343] ads7846_device: SPI devices registered: [ 7.125354] ads7846_device: spidev spi0.0 1000kHz 8 bits mode=0x00 [ 7.125357] ads7846_device: [ 7.125366] ads7846_device: Settings: [ 7.125369] ads7846_device: model = 7846 [ 7.125372] ads7846_device: gpio_pendown = 1 [ 7.125375] ads7846_device: swap_xy = 1 [ 7.125378] ads7846_device: x_min = 200 [ 7.125380] ads7846_device: x_max = 3900 [ 7.125383] ads7846_device: y_min = 200 [ 7.125386] ads7846_device: y_max = 3900 [ 7.125388] ads7846_device: x_plate_ohms = 60 [ 7.125391] ads7846_device: pressure_min = 0 [ 7.125393] ads7846_device: pressure_max = 255 [ 7.125396] ads7846_device: keep_vref_on = 1 [ 7.125398] ads7846_device: vref_delay_usecs = 0 [ 7.125401] ads7846_device: vref_mv = 0 [ 7.125403] ads7846_device: settle_delay_usecs = 0 [ 7.125406] ads7846_device: penirq_recheck_delay_usecs = 0 [ 7.125409] ads7846_device: y_plate_ohms = 0 [ 7.125411] ads7846_device: debounce_max = 0 [ 7.125414] ads7846_device: debounce_tol = 0 [ 7.125416] ads7846_device: debounce_rep = 0 [ 7.125425] ads7846_device: Deleting spi0.0 [ 7.126442] ads7846 spi0.0: spi0.0 supply vcc not found, using dummy regulator [ 7.144047] ads7846 spi0.0: touchscreen, irq 65 [ 7.144980] input: ADS7846 Touchscreen as /devices/platform/soc/1c68000.spi/spi_master/spi0/spi0.0/input/input1 [ 7.145055] ads7846_device: SPI devices registered: [ 7.145063] ads7846_device: ads7846 spi0.0 2000kHz 8 bits mode=0x00 [ 7.145066] ads7846_device: Of course, no touch events are detected. Anyone else have any luck getting this to work? I'm not familiar with changing the device tee to move GPIO pins, is there a configuration option for the spi_add_cs1?

Ahhh gotcha. Maybe that's probably a step I'm missing. I'll look back through the thread for it. Focusing on getting the LCD display to work first, I went to a different image, and went through the steps I previously did, but this time went through the steps on the lcd wiki to load the lcd driver (not the touch sensor yet). After reboot no real change. I checked Dmesg, and it does show the below, which is more than I got before (just the first line with the warning). (This was the result of using an older DTS) [ 5.598832] fbtft: module is from the staging directory, the quality is unknown, you have been warned. [ 5.608672] systemd[1]: Mounting sys-fs-fuse-connections.mount - FUSE Control File System... [ 5.614293] systemd[1]: Finished systemd-remount-fs.service - Remount Root and Kernel File Systems. [ 5.615861] systemd[1]: systemd-pstore.service - Platform Persistent Storage Archival was skipped because of an unmet condition check (ConditionDirectoryNotEmpty=/sys/fs/pstore). [ 5.620811] systemd[1]: Starting systemd-random-seed.service - Load/Save Random Seed... [ 5.621197] fb_ili9341: module is from the staging directory, the quality is unknown, you have been warned. [ 5.621724] sun50i-h616-pinctrl 300b000.pinctrl: supply vcc-pa not found, using dummy regulator [ 5.622378] fb_ili9341 spi0.0: fbtft_property_value: regwidth = 8 [ 5.622388] fb_ili9341 spi0.0: fbtft_property_value: buswidth = 8 [ 5.622400] fb_ili9341 spi0.0: fbtft_property_value: debug = 0 [ 5.622409] fb_ili9341 spi0.0: fbtft_property_value: rotate = 0 [ 5.622419] fb_ili9341 spi0.0: fbtft_property_value: fps = 10 [ 5.622583] sun50i-h616-pinctrl 300b000.pinctrl: pin PA7 already requested by spi0.0; cannot claim for 300b000.pinctrl:7 [ 5.622595] sun50i-h616-pinctrl 300b000.pinctrl: error -EINVAL: pin-7 (300b000.pinctrl:7) [ 5.622610] fb_ili9341 spi0.0: error -EINVAL: Failed to request reset GPIO [ 5.622649] fb_ili9341: probe of spi0.0 failed with error -22 (This was the below is the newer DTS this reply of Peters) [ 5.550586] fbtft: module is from the staging directory, the quality is unknown, you have been warned. [ 5.560145] fb_ili9341: module is from the staging directory, the quality is unknown, you have been warned. I noticed the difference between the older and newer DTS is pin assignments. I just compared the pinouts for the MPI3508 and the Orange Pi Zero 3 and everything seems to match up with their labels, with the one exception, on my OPiZ3, SPI1/CS/PH9(pin 24) is one pin above the TP_CS pin (26) on the MPI3508. I think another issue I'm having is the DTS that's been posted here is for the bigger Orange Pi, with the 40pin header, and my OPi has the 26pin header, which is the same count as that on the LCD. Because of that I probably need to rename/number something in the DTS, but I'm not sure what yet.

A new variation of Orange Pi 5 is now available. I think it's available on AliExpress, but I've seen the item on Amazon.com as well...reasonable price: https://www.amazon.com/Orange-Pi-Rockchip-Frequency-Development/dp/B0C5BZLPZN It comes now with the RK3588 instead of the RK3588s of the 5 and 5B. It's similar in capabilities of the Rock 5B but I believe has a few more bells and whistles. It has two 2.5GB ethernet ports. Separate connectors than GPIO for RTC and fan. Full size HDMI input as well as 2 full size HDMI outputs. Can have m.2 for 2230 WiFi/BT on top side as well as m.2 2280 on bottom of board. I think it can only go up to 16GB memory. Not sure if Armbian will make all of these work...yet. But this makes perfect sense...I just bouth my Orange Pi 5 about a month ago PS: A new tag is required for this new variation...I guess. PPS: Other thing to note is that Amazon link is for a 16GB version and includes a power supply. However, this particular listing ships from China. For Orange Pi 5 and 5B there were listings that were fulfilled by Amazon. I would think that Orange Pi will/may have those in the near future, that ship from the US...hopefully, but likely a little more expensive. PPPS: If you go to that Amazon link, there is also a version with 4GB and no power supply for $99.99 at the time this was posted.

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!

OK, so still at the nothing happens stage for me. Nothing on the HDMI or LCD. evtest comes back with /dev/input/event0: DELL DELL USB Keyboard /dev/input/event3: BRLTTY 6.5 Linux Screen Driver Keyboard Whatever that BRLTTY is (something to do with TTY service?), doesn't seem to be anything to do with the touch screen, as it doesn't show any input when I try it (though if the pins aren't right that could be it). gpioinfo for chip1 has 32 lines, I'm assuming that's where the GPIO would show up for the screen, but it says they're all unused. Chip0 has 287 lines, most seem to be unnamed/unused (see bottom for examples). After dinner, I'll see if I can get the HDMI to come back. I guess the next step is to check the pinouts on my OPiZ3 compared with the screen and with the pinout above where it's said to have worked. For reference, I'm using the latest image that @pixdrift provided in another thread (bookworm edge 6.7.4). However, I may try the previous one, as now that I look at it, the one I'm using now appears to have something to do with audio. Also, I went into Armbian config and turned on all the options for SPI and the TFT options as well. Maybe I'll go back and turn TFT off and run the command that added the DTS again. When I tried that it said it was already configured so might be interfering and not loading that DTS. line 64: unnamed kernel input active-high [used] line 65: unnamed unused input active-high line 66: unnamed kernel input active-high [used] line 67: unnamed kernel input active-high [used] line 68: unnamed kernel input active-high [used] line 69: unnamed unused input active-high line 70: unnamed unused input active-high line 71: unnamed unused input active-high line 72: unnamed unused input active-high line 73: unnamed "interrupt" input active-high [used] line 74: unnamed unused input active-high line 75: unnamed unused input active-high line 76: unnamed "red:status" output active-high [used] line 77: unnamed "green:power" output active-high [used] line 78: unnamed unused input active-high line 79: unnamed unused input active-high line 80: unnamed "regulator-usb1-vbus" output active-high [used] ... line 192: unnamed kernel input active-high [used] line 193: unnamed kernel input active-high [used] line 194: unnamed kernel input active-high [used] line 195: unnamed kernel input active-high [used] line 196: unnamed kernel input active-high [used] line 197: unnamed kernel input active-high [used] line 198: unnamed unused input active-high line 199: unnamed unused input active-high line 200: unnamed unused input active-high line 201: unnamed unused input active-high line 202: unnamed unused input active-high line 203: unnamed unused input active-high line 204: unnamed unused input active-high line 205: unnamed unused input active-high line 206: unnamed unused input active-high line 207: unnamed unused input active-high line 208: unnamed unused input active-high line 209: unnamed unused input active-high line 210: unnamed "reset" output active-low [used]

@svdmk Thanks for posting the photos and the firmware! I took a look to the device tree and found something that could be somehow intersting. I'm not absolutely sure it may be related to your issue, but there the device tree contains this gpio switch which is not usual: gpio_poweroff { compatible = "gpio-poweroff"; gpios = <0xb3 0x11 0x01>; status = "okay"; }; it maps to gpio3 bank and pin 17 (PC1, in the rockchip documentation). That string says that the pin is active low, it means that when it is 0, the poweroff is active; when it is 1 the poweroff is inactive. I may assume that gpio pin is used by the operating system to power off the system. On other board that pin is not mapped in the device tree, so I may also assume it is not used anywhere. In your case may (or may not) be related to the weird behaviour you're experiencing. With this command (to be run as root), you can see how the pins is configured. In my case, the pin is set to output at 0 level, but since it is not wired on my board it just does not do anything. Could you please execute the same command on your board? # grep 'gpio3-17' /sys/kernel/debug/pinctrl/pinctrl-rockchip-pinctrl/pinconf-pins pin 113 (gpio3-17): input bias pull down (1 ohms), output drive strength (8 mA), pin output (0 level) You can also control that pin: # cd /sys/class/gpio # echo 113 > export # cd gpio113 # cat direction in # cat value 0 # echo out > direction # cat direction out # echo 1 > value # cat value 1 # echo 0 > value # cat value 0 with echo 113 > export you will make the pin available for userspace, then a directory gpio113 will spawn and you can echo to direction and value to change the pin as input or output and switch levels. If the pin is actually wired to something, it may be that when you switch direction of level the board may suddenly turn off. Now you can also do another test: erase the emmc and verify you still have the shutdown issue. If that is the case, it may be interesting to see what is the pin state in that condition and if switching its condition causes the weird behaviour to stop or does not change anything.

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"

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?

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