Search the Community

I found more information on 32kHz clock. Starting at page 275. https://www.scs.stanford.edu/~zyedidia/docs/allwinner/h616.pdf 3.13.3.4.6. RC Calibration The basic circuit of RC calibration is shown in Figure 3-39. Whether to output the calibrated RC clock can be selected by the RC_Cali_SEL control bit, the calibration principle is as follows. http://nskhuman.ru/allwinner/h616reglist.php?nreg=153 3.13.3.5.3. Fanout Set the bit0 of 32K_FANOUT_GATING_REG to 1, and ensure that external pull-up resistor and voltage are normal, then 32.768 kHz fanout square wave can be output. Fanout: The clock source of fanout can select RTC_32K, or 32K divided by PLL_PERI(2X), or 32K divided by HOSC. http://nskhuman.ru/allwinner/h616reglist.php?nreg=161 /* * There are other differences between models, including: * * - number of GPIO pins that can be configured to hold a certain level * - crypto-key related registers (H5, H6) * - boot process related (super standby, secondary processor entry address) * registers (R40, H6) * - SYS power domain controls (R40) * - DCXO controls (H6) * - RC oscillator calibration (H6) * * These functions are not covered by this driver. */ I guess there's no function to calibrate the internal RC oscillator yet. https://github.com/torvalds/linux/blob/master/drivers/rtc/rtc-sun6i.c This is the 32K_FANOUT_GATING_REG. #define SUN6I_LOSC_OUT_GATING 0x0060 rtc->ext_losc = clk_register_gate(NULL, clkout_name, init.name, 0, rtc->base + SUN6I_LOSC_OUT_GATING, SUN6I_LOSC_OUT_GATING_EN_OFFSET, 0, &rtc->lock); If we can find out which clock source we are using and change it to something more accurate? All though, Calibrating the RTC is the ideal solution. On these cheap boxes there is no external 32KHz oscillator.

I try to boot for first time an espresso bin v5, I followed the advice in (Espressobin / Ultra – Armbian](https://www.armbian.com/espressobin/) and updated my uboot, and reset the environment. env default -a ## Resetting to default environment I added the image and fdt address with: setenv fdt_name boot/dtb/marvell/armada-3720-espressobin.dtb setenv image_name boot/Image setenv scriptaddr 0x6d00000 The last line is after seeing in the forum that this setting has been erased when resetting the default environment my environment is now: When I try to boot, it seems to load the initrd but never complete the boot I get: Marvell>> boot *** ERROR: `serverip' not set *** ERROR: `serverip' not set ... booting from SD 1631 bytes read in 9 ms (176.8 KiB/s) ## Executing script at 00800000 load - load binary file from a filesystem Usage: load <interface> [<dev[:part]> [<addr> [<filename> [bytes [pos]]]]] - Load binary file 'filename' from partition 'part' on device type 'interface' instance 'dev' to address 'addr' in memory. 'bytes' gives the size to load in bytes. If 'bytes' is 0 or omitted, the file is read until the end. 'pos' gives the file byte position to start reading from. If 'pos' is 0 or omitted, the file is read from the start. ## Info: input data size = 2100 = 0x834 load - load binary file from a filesystem Usage: load <interface> [<dev[:part]> [<addr> [<filename> [bytes [pos]]]]] - Load binary file 'filename' from partition 'part' on device type 'interface' instance 'dev' to address 'addr' in memory. 'bytes' gives the size to load in bytes. If 'bytes' is 0 or omitted, the file is read until the end. 'pos' gives the file byte position to start reading from. If 'pos' is 0 or omitted, the file is read from the start. bootm - boot application image from memory Usage: bootm [addr [arg ...]] - boot application image stored in memory passing arguments 'arg ...'; when booting a Linux kernel, 'arg' can be the address of an initrd image When booting a Linux kernel which requires a flat device-tree a third argument is required which is the address of the device-tree blob. To boot that kernel without an initrd image, use a '-' for the second argument. If you do not pass a third a bd_info struct will be passed instead Sub-commands to do part of the bootm sequence. The sub-commands must be issued in the order below (it's ok to not issue all sub-commands): start [addr [arg ...]] loados - load OS image ramdisk - relocate initrd, set env initrd_start/initrd_end fdt - relocate flat device tree cmdline - OS specific command line processing/setup bdt - OS specific bd_t processing prep - OS specific prep before relocation or go go - start OS 21764608 bytes read in 2021 ms (10.3 MiB/s) ext4load - load binary file from a Ext4 filesystem Usage: ext4load <interface> [<dev[:part]> [addr [filename [bytes [pos]]]]] - load binary file 'filename' from 'dev' on 'interface' to address 'addr' from ext4 filesystem 11618 bytes read in 12 ms (945.3 KiB/s) ## Flattened Device Tree blob at 06f00000 Booting using the fdt blob at 0x6f00000 Using Device Tree in place at 0000000006f00000, end 0000000006f05d61 Starting kernel ... [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034] [ 0.000000] Linux version 5.15.48-mvebu64 (root@8b3d501f9218) (aarch64-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36)) 8.3.0, GNU ld (GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36)) 2.32.0.20190321) #22.05.3 SMP PREEMPT Wed Jun 22 07:22:16 UTC 2022 [ 0.000000] Machine model: Globalscale Marvell ESPRESSOBin Board [ 0.000000] earlycon: ar3700_uart0 at MMIO 0x00000000d0012000 (options '') ..... Omitted a long boot log .... [ 2.376178] Key type fscrypt-provisioning registered [ 2.383950] Btrfs loaded, crc32c=crc32c-generic, zoned=no, fsverity=no [ 2.394740] d0012000.serial: ttyMV0 at MMIO 0xd0012000 (irq = 0, base_baud = 1562500) is a mvebu-uart [ 2.404251] printk: console [ttyMV0] enabled [ 2.404251] printk: console [ttyMV0] enabled [ 2.412987] printk: bootconsole [ar3700_uart0] disabled [ 2.412987] printk: bootconsole [ar3700_uart0] disabled [ 2.425972] xenon-sdhci d00d0000.sdhci: Got CD GPIO [ 2.464648] mmc0: SDHCI controller on d00d0000.sdhci [d00d0000.sdhci] using ADMA [ 2.473851] Waiting for root device ... [ 2.512635] mmc0: new high speed SDHC card at address d6d7 [ 2.520455] mmcblk0: mmc0:d6d7 SU08G 7.40 GiB [ 2.531514] mmcblk0: p1 It seems that my boot env is incomplete. I tried with the last bullseyes and bookworm image, with the same result. I also tried the instructions in Armbian Documentation - Esspresso bin even if it seems obsolete by now, as it uses old uboot variable names, and contain a booiti command after sourcing the boot.scr script which itself contain the booti command; but I got the same result, even if the inird addr was distinct. Please what is wrong, and what I'm missing in this uboot environment.

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.

Hi, I have a board Orange Pi Zero with modified PAs for power of WiFi module from PA20 to PA02, by soldering a connection on board. This is done to allow connection of I2C DAC. I see that board definition in 'u-boot/configs/orangepi_zero_defconfig' It uses dts definition of: 'arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts' I need to modify one section of this dts file from: reg_vcc_wifi: reg_vcc_wifi { compatible = "regulator-fixed"; regulator-min-microvolt = <3300000>; regulator-max-microvolt = <3300000>; regulator-name = "vcc-wifi"; enable-active-high; gpio = <&pio 0 20 GPIO_ACTIVE_HIGH>; to: reg_vcc_wifi: reg_vcc_wifi { compatible = "regulator-fixed"; regulator-min-microvolt = <3300000>; regulator-max-microvolt = <3300000>; regulator-name = "vcc-wifi"; enable-active-high; gpio = <&pio 0 2 GPIO_ACTIVE_HIGH>; How can I do this and use armbian build script: compile.sh Thanks, Michal

If I connected the serial port with my device through GPIO pin 8 and 10 (UART_AO_A_TXD, UART_AO_A_RXD), the Radxa Zero with " Armbian 23.02.2 Jammy" failed to boot. If I removed my device from the serial port, zero can boot. After booting, I connected my device to the UART port, it worked well through /dev/ttyAML0. Any suggestions? Many thanks!

Hello, I tried ` echo 463 > /sys/class/gpio/export ` and it build gpio464 folder under /sys/class/gpio , and I cat `value` file to check gpio status. It seems not work. The same gpio was working on Bananapi official debian and Ubuntu mate image. How can I solve this problem? Thanks

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.

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'm using image Armbian_23.8.3_Orangepizero2_bookworm_current_6.1.53 I'm building a DTS overlay for a SPI Touchscreen and every pin I try to use is showing this error: [ 1.441808] sun50i-h616-pinctrl 300b000.pinctrl: pin PC11 already requested by 5011000.spi; cannot claim for 300b000.pinctrl:75 [ 1.441817] sun50i-h616-pinctrl 300b000.pinctrl: pin-75 (300b000.pinctrl:75) status -22 [ 1.441829] sun6i-spi 5011000.spi: cannot register SPI master I'm trying to configure my touchscreen dts to use the SPI1.0 & SPI1.1. However, the pins exposed on the headers are all allocated for device use under 300b000.pinctrl. How do you allocate header pins for another use? I need 5 pins + SPI1 for the touchscreen to work. My dts /dts-v1/; /plugin/; / { compatible = "allwinner,sun8i-h3"; fragment@0 { target = <&pio>; __overlay__ { spi1_cs1: spi1_cs1 { pins = "PC11"; function = "gpio_out"; output-high; }; opiz_display_pins: opiz_display_pins { pins = "PC9", "PC6", "PC5"; function = "gpio_out"; }; ads7846_pins: ads7846_pins { pins = "PH6"; function = "irq"; }; }; }; fragment@1 { target = <&spi1>; __overlay__ { #address-cells = <1>; #size-cells = <0>; status = "okay"; pinctrl-1 = <&spi1_cs1>; pinctrl-names = "default", "default"; cs-gpios= <0>, <&pio 2 11 0>; /* PH9 PC11 */ opizdisplay: opiz-display@0 { reg = <0>; /* Chip Select 0 */ compatible = "ilitek,ili9341"; spi-max-frequency = <16000000>; status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&opiz_display_pins>; rotate = <90>; bgr = <0>; fps = <10>; buswidth = <8>; dc-gpios = <&pio 2 6 0>; /* PC6 */ reset-gpios = <&pio 2 9 1 >; /* PC9 */ led-gpios=<&pio 2 5 0>; /* PC5 */ debug=<0>; }; ads7846: ads7846@1 { reg = <1>; /* Chip Select 1 */ compatible = "ti,ads7846"; spi-max-frequency = <500000>; status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&ads7846_pins>; interrupt-parent = <&pio>; interrupts = <7 6 2>; /* PH6 IRQ_TYPE_EDGE_FALLING */ pendown-gpio = <&pio 7 6 0>; /* PH6 */ /* driver defaults, optional */ ti,x-min = /bits/ 16 <0>; ti,y-min = /bits/ 16 <0>; ti,x-max = /bits/ 16 <0x0FFF>; ti,y-max = /bits/ 16 <0x0FFF>; ti,pressure-min = /bits/ 16 <0>; ti,pressure-max = /bits/ 16 <0xFFFF>; ti,x-plate-ohms = /bits/ 16 <400>; }; }; }; };

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

@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.

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.

Hello there. I'm trying to set up GPIO pins PD15 and PD16 on my OrangePi 3 LTS to work as input pins using device tree overlays. The overlay I have created is the following (for PD15 only): /dts-v1/; /plugin/; / { compatible = "allwinner,sun50i-h6"; fragment@0 { target = <&pio>; __overlay__ { my_pins:my_pins { pins = "PD15"; function = "gpio_in"; default-state = "on"; }; }; }; fragment@1 { target-path = "/"; __overlay__ { my@0 { compatible = "my-gpio"; pinctrl-names = "default"; pinctrl-0 = <&my_pins>; gpios = <&pio 3 15 0>; status = "okay"; }; }; }; }; Probably it is incorrect, because when I check the GPIO state using "gpio readall" command, I still get OFF state for the PD15 pin. Of course, I could change the pin mode using the "gpio" command itself (it does work, like "gpio mode 9 in" does set the PD15 pin mode to input), but I would prefer the overlays method.

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!

As the title says. I can not get PWM to work. I can type gpio mode 2 pwm and no error. But when I try to access it from Klipper (3D Printer Software and Firmware) it won't work. However if I use gpio 3, in software, gpio 4 turns on. Please help me out here. Thanks, Kevin

So what I want is to control 433Mhz power plugs from my orange pi. I have both a sender and a receiver module that get connected via the gpio pins. For the plugs I have a remote control and now i need a way to replicate that behaviour - ie I need a program that can sniff the 433Mhz signal coming from the remote control and analyze it in such a form that I can send it out again via the sender. In the good old sysfs times there were tools (like the 433Utils I mentioned above) that could do that - and my question is how this is done today...

You have provided far too little context, and I do not understand what you are talking about. But if it's just the output of a pattern waveform via a GPIO, you can do it with a one-liner from the command line: gpioset --toggle 100ms,100ms,100ms,100ms,100ms,300ms,300ms,100ms,300ms,100ms,300ms,300ms,100ms,100ms,100ms,100ms,100ms,700ms --consumer panic con1-08=active This is just an example and the emitted pattern doesn't meet your needs, but with adjusted timings it does exactly what you want. Of course, you can also write your application with program code. Libgpiod provides bindings for C++, python3 and Rust therefor.