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.

Hi, I've opened with tag orangepiprime because there was no a64 tag eventhough in the Armbian site is flagged as standard support, tell me if i have to reopen it elsewhere. Anyhow I'm constantly getting kernel panics during boot, I've tested images minimal/cli images starting from 23.5.1 down to 24.5.0 (just downloaded the image and flashed with balena etcher), attached there are all the serial logs of the boot processes, all of them are the same more or less. I've tried: powering from GPIO changing powersupply changing usb cable 4 different uSD cards changing the board hooking it up to a display and none of them worked. What else can I try? Armbian_24.5.0-trunk.223_Pine64_trixie_current_6.6.22_minimal.img.xz.log Armbian_24.2.1_Pine64_bookworm_current_6.6.16_minimal.img.xz.log Armbian_23.11.1_Pine64_bookworm_current_6.1.63.img.xz.log Armbian_23.8.1_Pine64_bookworm_current_6.1.47.img.xz.log Armbian_23.5.1_Pine64_bookworm_current_6.1.30.img.xz.log

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.

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.

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.

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

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?

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.

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.

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.

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.

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?

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.

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

Description Enable uboot gpio command. This would allow to set up rk3318-box'es LED display in custom uboot script. For example, to show "boot", this snippet can be added (gpio pins and letter codes should be adjusted for different STB/LCD models): FD650_MODE_WRCMD='0 1 0 0 1 0 0 0' DISPON='0 0 0 0 0 0 0 1' FD655_BASE_ADDR='0 1 1 0 0 1 1 0' Z='0 0 0 0 0 0 0 0' B='0 1 1 0 0 1 1 1' O='0 1 1 0 0 0 1 1' T='0 1 0 0 0 1 1 1' setenv d0 gpio clear C22 setenv d1 gpio set C22 setenv LC gpio clear C19 setenv HC gpio set C19 setenv send 'run d0 LC; for b in $cmd; do run d$b HC LC; done; run HC d1' cmd="$FD650_MODE_WRCMD 1 $DISPON 1" run send cmd="$FD655_BASE_ADDR 1 $Z 1 $B 1 $O 1 $O 1 $T 1" run send How Has This Been Tested? Please describe the tests that you ran to verify your changes. Please also note any relevant details for your test configuration. [x] Compile and boot rk3318-box Checklist: [ ] My code follows the style guidelines of this project [ ] I have performed a self-review of my own code [ ] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [ ] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article

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

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

Hi, I have orange pi 5. I searched all over internet for information how to set on startup/power on GPIO pins behavior, but i cannot find anything. Most of GPIO pins are set to IN mode 1. Sadly I need them to output mode 1. I am scared something could burn this way since i set them to though wiringPI after kernel boot sequence is complete. Can some one give information how I can set them up at earlier point when I power on the board? I found that DTB/DTS file could do it. But there is no clear information / pin addresses I should set. Thanks in advance! Regards!

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

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