hasselh

FYI: I just recognized that with kernel upgrades the /boot/dtb symlink changes to the new installed directory. Hence giving a different DTB file name inside of /boot/dtb will not help. Also specifying a fully qualified filename (outside of /boot/dtb) unfortunately seems not to work

Yes, this was the culprit. I now successfully applied the overlay and my good old S0/1Wire adapter (originated from Gen-1 Raspberry Pi) continues to run with Debian Buster/5.9.14 kernel on my Hummingboard… Thank you very much for your help !! One thing I noticed is that each apt-get upgrade now comes with the risk/extra effort that /boot/dtb gets overwritten and I have to adapt & apply the overlay again (it looks like adding overlays= in armbianEnv.txt doesn't work either). FYI: In the past I was simply doing the muxing of 8 GPIO pins "on the fly" during OS start with: for mux in 00f8 00fc 0100 012c 0134 0138 02b8 02bc; do /usr/local/sbin/busybox devmem 0x020e$mux 32 0x15; done This had the big advantage that this solution was persistent across multiple OS and kernel flavors. But muxing "on the fly" with 5.x kernels seems no more an option, or ?

OK, I found a description of the registers I need at https://elixir.bootlin.com/linux/latest/source/arch/arm/boot/dts/imx6q-pinfunc.h . Still I feel a bit uncomfortable, as I have no experience if 0x40013070 setting is the correct value. In the past I was setting the mux register to 0x15 as GPIO input. So I modified your file to currently only "play" with gpio70: then successfully compiled with dtc -I dts -O dtb -o imx6q-hummingboard-gpio.dtbo imx6q-hummingboard-gpio.dts and then tried to apply with fdtoverlay. But "something" fails (-v didn't help): root@hummingboard:/boot/dtb# fdtoverlay -v -i imx6q-hummingboard.dtb.orig -o imx6q-hummingboard.dtb imx6q-hummingboard-gpio.dtbo input = imx6q-hummingboard.dtb.orig output = imx6q-hummingboard.dtb overlay[0] = imx6q-hummingboard-gpio.dtbo Failed to apply imx6q-hummingboard-gpio.dtbo (-1) Any idea what I might have done wrong ? Frohe Weihnachten !!

Ok, setting correct DTB via by inserting setenv fdt_file "imx6q-hummingboard.dtb" to /boot/boot.cmd and then recompiling with: mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr worked like a charm. The output looks much better now… root@cubox-i:~# cat /sys/firmware/devicetree/base/model SolidRun HummingBoard Dual/Quad Still I didn't find a way to mux my pins. Formerly I was writing 0x15 (according SolidRun forum: 0x5 is gpio mux and the 0x10 is SION bit which must be enabled in order to read from that gpio) into respective mux registers. Is there still a way to do that post boot (from user space) ? If not, where do I find any documentation/examples how to properly create the correct DT-overlays for my Hummingboard ?

imx6q-hummingboard.dtb is listed under /boot/dtb in current Hummingboard images (https://www.armbian.com/hummingboard/). But how can I tell Armbian to use it at boot time ? Also, any idea how to mux GPIO pins under 5.x kernels ?

Hi usual user sorry for my late reply (unless somebody likes one of my posts, during the 1st week I am only able to write one post per day in this forum ;o). FYI only: In the past (in 4.x kernel based Armbian releases) /sys/firmware/devicetree/base/model and /sys/kernel/debug/gpio looked like the following: gpiochip0: GPIOs 0-31, parent: platform/209c000.gpio, 209c000.gpio: gpio-0 ( |usb_h1_vbus ) out hi gpio-4 ( |cd ) in lo gpiochip1: GPIOs 32-63, parent: platform/20a0000.gpio, 20a0000.gpio: gpio-58 ( |spi_imx ) out hi gpio-59 ( |spi_imx ) out hi gpiochip2: GPIOs 64-95, parent: platform/20a4000.gpio, 20a4000.gpio: gpio-69 ( |gpio-ir-recv ) in hi gpio-83 ( |brcm_reg ) out lo gpio-86 ( |usb_otg_vbus ) out hi gpiochip3: GPIOs 96-127, parent: platform/20a8000.gpio, 20a8000.gpio: gpio-111 ( |phy-reset ) out hi gpiochip4: GPIOs 128-159, parent: platform/20ac000.gpio, 20ac000.gpio: gpio-133 ( |sdio-clock ) out lo gpio-154 ( |reset ) out lo gpiochip5: GPIOs 160-191, parent: platform/20b0000.gpio, 20b0000.gpio: gpio-160 ( |reset ) out lo gpiochip6: GPIOs 192-223, parent: platform/20b4000.gpio, 20b4000.gpio: And since 5.x kernels it looks like the following: root@cubox-i:~# cat /sys/firmware/devicetree/base/model SolidRun Cubox-i Dual/Quad root@cubox-i:~# cat /sys/kernel/debug/gpio gpiochip0: GPIOs 0-31, parent: platform/209c000.gpio, 209c000.gpio: gpio-0 ( |regulator-v-usb2 ) out hi gpio-4 ( |cd ) in lo ACTIVE LOW gpiochip1: GPIOs 32-63, parent: platform/20a0000.gpio, 20a0000.gpio: gpiochip2: GPIOs 64-95, parent: platform/20a4000.gpio, 20a4000.gpio: gpio-72 ( |Button 0 ) in hi ACTIVE LOW gpio-73 ( |ir-receiver ) in lo ACTIVE LOW gpio-83 ( |brcm-reg ) out lo gpio-86 ( |regulator-v-usb1 ) out hi gpiochip3: GPIOs 96-127, parent: platform/20a8000.gpio, 20a8000.gpio: gpio-111 ( |phy-reset ) out hi gpiochip4: GPIOs 128-159, parent: platform/20ac000.gpio, 20ac000.gpio: gpio-133 ( |enable ) out lo gpio-154 ( |reset ) out lo ACTIVE LOW gpiochip5: GPIOs 160-191, parent: platform/20b0000.gpio, 20b0000.gpio: gpio-160 ( |reset ) out lo ACTIVE LOW gpiochip6: GPIOs 192-223, parent: platform/20b4000.gpio, 20b4000.gpio: Hence I am not able to set an IRQ to gpio-72 and gpio-73 on 5.x kernels: root@cubox-i:~# echo 73 > /sys/class/gpio/export -bash: echo: write error: Device or resource busy root@cubox-i:~# echo "rising" > /sys/class/gpio/gpio73/edge -bash: /sys/class/gpio/gpio73/edge: No such file or directory And writing to /dev/mem (for muxing the GPIO pins) is not permitted either: root@cubox-i:~# busybox devmem 0x020e0138 32 0x15 devmem: mmap: Operation not permitted I think the culprit is noted for v19.11.3 (2019-11-20) in https://docs.armbian.com/Release_Changelog/ [AR-24] - Drop cubox family and move Cubox/Hummingboard boards under imx6 The Hummingboard shows still as supported for Armbian. Is there any way to migrate to a current Armbian image without loosing the ability to mux and (re-) assign existing GPIO pins ?

Hello, I am running Armbian on my Hummingboard i2eX, currently with Debian Buster on 4.9.7 kernel. For running some legacy HW (s0vz, counting impulses) I have to mux several GPIO pins to use them for input. Following http://www.solid-run.com/community/topic1571.html on 4.x kernel, I always was able to mux e.g. gpio-73 with devmem 0x020e0138 32 0x15 and then set the pin for input with: echo 73 > /sys/class/gpio/export echo "rising" > /sys/class/gpio/gpio73/edge Starting with 5.x kernel based Armbian images, I have 2 issues: muxing any IO pins with devmem seems no more possible and gpio72 is now reserved for Button 0 and gpio-73 is reserved for IR-receiver (which before was on gpio-69). So any manipulation through /sys/class/gpio fails With Buster on 5.x kernels... does anyone have an idea how I can continue to mux my Hummingboard IO pins and remove incorrect assignments for IR-receiver and Button 0 ? Thanks in advance for your help