Yes, as you’ve noticed only certain pins are configured and usable as GPIOs by default. In order to have access to more pins as GPIOs you’ll need to make changes in the device tree.
We do provide a tools container that lets you apply a device tree overlay so that you may make minor changes such as this without recompiling and redeploying the entire device tree. Details on this container can be found here: Device Tree Overlays on Torizon | Toradex Developer Center
There is also a section at the end of that article that provides a reference overlay that can be used to configure additional GPIOs. One important thing to keep in mind though is that many pins are already used by other hardware interfaces. So when you configure a pin as a GPIO you’ll need to take care as to resolve any conflicts and make sure the pin is not already in use. This may require disabling interfaces that use the pins that you want to use.
We don’t have a documented example but perhaps we should, thank you for the feedback on that.
So to explain, the pinctrl node &pinctrl_my_gpios you see in the example gets created by the overlay itself. Really you can call the node whatever you want just rename &pinctrl_my_gpios in that example.
Using GPIO4_IO21 as an example again here’s an example overlay that should configure it as a GPIO:
Thank you very much!! That makes it somewhat clear how this should work.
Now I understand the output of the NXP pin tool (pin names and hex values).
But somehow I cannot make it build.
I tried the exact example you provided and tested in the torizon/arm64v8-debian-dev-tools docker container with the following result:
root@5bd024a1f776:/# dtconf build --no-git-repo /tests/gpio_test_forum.dts
Device is apalis imx8(0037)
Mounting /mnt/part
Failed to build device tree.
Error: /panda/gpio_test_forum.dts:12.62-66 syntax error
FATAL ERROR: Unable to parse input tree
So the important thing to note now is that there’s an include statement at the top. As you can imagine in the source code SC_P_QSPI1A_SCLK_LSIO_GPIO4_IO21 is just a variable name to define the various pins on the SoC. However we need to include this file in our overlay so that our overlay has the pin definitions when it compiles.
This seems like the case where this pin may have already been in use or configured somewhere in the device tree. In order to disable this overly from the u-boot console you can do the following:
ums 0 mmc 0 This command will attach the internal eMMC of the module to your development PC as a USB device. You’ll need the USB OTG attached for this
Once attached you’ll need to look in the BOOT partition. There should be an overlays text file you can simply just delete this file.
Once the overlays file has been deleted you can just boot as normal and the overlay shouldn’t load.
I did a quick test on my i.MX8 and I was able to set GPIO4_IO21 as an output and toggle it’s value using the sysfs interface. This is with no modifications to the device tree. Earlier you said this pin was not configurable, how were you accessing GPIOs initially?
i used TEZI from SD-card via serial interface to mount the boot partition and delete the file, which worked (custom board without USB OTG).
You are correct - the newest beta3 of Torizon 4.0.0 seems to switch GPIO4_IO21 fine without overlays.
I had problems with an older image from CI server.
The problem persists for Apalis GPIO-8 (GPIO3_IO28), which seems to be used by:
line 28: unnamed "GPIO fan control" output active-high [used]
Changing the output with gpioset does not work and returns:
# gpioset /dev/gpiochip3 28=0
gpioset: error setting the GPIO line values: Device or resource busy
I used the docker image “torizonextras/arm64v8-gpiod” and “gpioinfo” / “gpioset” tools in the image as described in the article “How to Use GPIO on TorizonCore”.
As you’ve noticed with GPIO3_IO28, by default it is the GPIO used for the fan control. Now this is a question of whether you require the fan control to be working. If no then it is a simple matter of disabling this interface which should free up this pin. If yes then you’ll need to shuffle around pins and provide a substitute GPIO pin for the fan control to use.
So do you need this gpio-fan interface operational? And if yes do you have a GPIO pin in your system you can give up as a substitute?
I don’t need the fan control - we use a custom board with the fan always on.
How do i turn off an interface (in this case the fan control and ? Is it possible with device tree overlays?
Another pin I’d like to use is already in use (despite being marked as “GPIO” on Apalis modules): GPIO3 pin 26 (aka “Apalis-GPIO7”). It is used as “pcie_switch” output (from “gpioinfo” command).
First with Apalis GPIO7 this pin gets used by interface Apalis PCIE 1. A simple matter of disabling this interface, if you don’t require it, should do. This can be done easily with an overlay.
Next with Apalis GPIO8 as we’ve already discussed is used by the gpio-fan interface. Unfortunately as far as I can tell there’s no easy way to just “disable” this, meaning if you don’t want it, the simplest way would be to just remove the device tree node from the source and recompile.
Due to the gpio-fan issue it’d probably just be best to recompile the device tree from source with changes rather than use an overlay here.
As such I’ve gone ahead and done just that here’s a compiled device tree binary that should enable GPIO7 & 8 as free GPIOs: https://share.toradex.com/i59lzb33zp0328e
In order to have your device load this device tree you’ll need to replace the default device tree at this location on the device’s filesystem: /boot/ostree/torizon-{some random checksum}/fsl-imx8qm-apalis-eval.dtb. Once you’ve replaced this with the new device tree a simple reboot of the device should load this new configuration.
You can use this patch if you ever need to recompile the device tree with these changes yourself, or simply as a reference of how you could do similar changes. Just as a note as you might notice in the changes I completely removed gpio-fan which you said you didn’t need. But I also disabled Apalis PCIE1 in order to free up GPIO 7. If you need this PCIE you’ll need to substitute another GPIO pin and re-enable the interface.
This post was over 2 years ago I no longer have the code that I shared back then, nor do I even remember what I did.
Also in the context of this original question the software versions used are much older than what you’re probably currently working with. So the answer given back then may not even be applicable to the software versions used today.
I’d recommend just creating a new post with your question and details.