Jump to content

Muxing GPIO on Hummingboard i2eX on 5.x kernel

hasselh

By hasselh
in Beginners

 Share
Go to solution Solved by usual user,

Recommended Posts

hasselh

hasselh

Posted
Posted

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:

  1. muxing any IO pins with devmem seems no more possible and
  2. 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

hasselh

hasselh

Posted
  • Author
Posted

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 ?

usual user

usual user

Posted
Posted
1 hour ago, hasselh said:

SolidRun Cubox-i Dual/Quad

Useing imx6q-cubox-i.dtb for hummingboard carrier won't work. You need imx6q-hummingboard.dtb. In my environment I use mainline uboot build with mx6cuboxi target and distro-boot method. This way uboot identifies at which SolidRun imx6 device it is running and selects the appropriate DTB.
IIRC Armbian uses also mainline uboot but boot.scr magic to select the DTB.

hasselh

hasselh

Posted
  • Author
Posted

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 ?

usual user

usual user

Posted
Posted
4 hours ago, hasselh said:

But how can I tell Armbian to use it at boot time ?

Either fix the boot.scr magic or switch to distro-boot by inserting an extlinux.conf. For background maybe start reading here and here.

 

4 hours ago, hasselh said:

Also, any idea how to mux GPIO pins under 5.x kernels ?

I usually write DT-overlays for my board extensions and apply them to the base DTB.

hasselh

hasselh

Posted
  • Author
Posted

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 ?

usual user

usual user

Posted
Posted
On 12/23/2020 at 6:31 PM, hasselh said:

where do I find any documentation/examples how to properly create the correct DT-overlays for my Hummingboard ?

Maybe somthing like imx6q-hummingboard-gpio.dts. Compile it with DTC and apply it as follows: 

mv imx6q-hummingboard.dtb imx6q-hummingboard.dtb.orig
fdtoverlay -i imx6q-hummingboard.dtb.orig -o imx6q-hummingboard.dtb imx6q-hummingboard-gpio.dtbo

But since I don't know your PAD configuration requirements, I only chose one random one. You
 have to look up your needs yourself.

imx6q-hummingboard-gpio.dts

hasselh

hasselh

Posted
  • Author
Posted (edited)

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:

Spoiler

 

/dts-v1/;

/plugin/;

 

/ {

              compatible = "solidrun,hummingboard/q";

};

 

&{/soc/bus@2000000/pinctrl@20e0000} { /* &iomuxc */

              pinctrl-names = "default";

              pinctrl-0 = <&pinctrl_hog>;

 

              hog {

                             pinctrl_hog: hoggrp {

                                           fsl,pins = <

                                                             0x12c 0x440 0x000 0x5 0x0 0x40013070 /* MX6QDL_PAD_EIM_DA6__GPIO3_IO06 */

                                           >;

                             };

              };

};

 

 

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 !! :rolleyes:

Edited by hasselh
usual user

usual user

Posted
Posted
14 hours ago, hasselh said:

Any idea what I might have done wrong ?

Applies for me flawless. 

fdtoverlay -V
Version: DTC 1.6.0

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

The overlay is written for DTS comming with 5.10.0 kernel. Over time, some node names have been renamed to improve homogeneity. Attempting to apply it to an older release may fail.

hasselh

hasselh

Posted
  • Author
Posted

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 !! :D

 

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 ?

  • Solution
usual user

usual user

Posted
  • Solution
Posted
On 12/28/2020 at 10:12 PM, hasselh said:

risk/extra effort that /boot/dtb gets overwritten and I have to adapt & apply the overlay again

IMHO I think from version 5.10.0 the path won't change again because generic node names have been around since then. Therefore, the same DTBO can always be applied. But as long as the hardware setup doesn't change, there's no reason to ever change the DTB. Therefore, after an update, restoring the DTB from a persistent location  would also be an option.

But I guess you will have more fun to keep having the boot.scr magic in place. And tinkering with boot.scr magic opens even the option to load the DTB from the persistent location direct or choose a different DTB file name that wouldn't be overwritten.

hasselh

hasselh

Posted
  • Author
Posted
Quote

tinkering with boot.scr magic opens even the option to load the DTB from the persistent location direct or choose a different DTB file name that wouldn't be overwritten

 

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

Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept