Setting internal pull ups from the command line

Question

I’m learning how to control the gpio via the Linux kernel and have been working with inputs (specifically switches.) Recently I've been exploring pull up resistors. I’m wondering how I can initiate internal pull up resistors via the kernel as it is a lot simpler than making pull up resistor hardware. I know that there must be some way to do it through the kernel, as other libraries like the gpiod or rpi.gpio have the feature and use the kernel in their source code.

Currently, here are the commands I use to access the gpio of the kernel:

Cd /sys/class/gpio
Echo 25 > export
Cd gpio25
Echo in > direction
nano value

But due to a lack of documentation on the kernel, I don’t know where to go from here to activate pull ups. Could you please share some guidance on what to do next to access internal pull ups?

• Bibibou: You should have a look at this question. I think it will answer yours.
• Milliways: You don't seem to have got the message sysfs has been deprecated for years; no one ACTUALLY uses it (and hasn't for almost a decade) and it is a clumsy kludge. It will finally disappear - probably in the next kernel upgrade. What problem do you ACTUALLY have with the recommended tools. For that matter what are you actually trying to do?
• Matthew Moller: @Milliways I find libgpiod to be a solid library. It just doesn't support as many features as I'd like it to, like pwm. That's my main issue. I just want a library/module that has all the features, and is still compatible with the Raspberry Pi 5, but, I have struggled to find one.
• Matthew Moller: @Bibibou Yes, it seems as though there is no way to use Pull up's via the terminal.
• Matthew Moller: @Milliways I think I've got a pretty good idea of what I should do. Either use pinctrl, gpiod or just don't use pull ups at all.

Answer 1

You should take a look at pinctrl. It's not available as a 'package', which means you'll need to clone the repo using git, and build it from sources (see the Build Instructions in the README). It's not difficult at all:

$ cd
$ git clone https://github.com/raspberrypi/utils.git 
#
# this creates a copy of the entire "utils" repo in a `utils` folder in your home dir
# Afterwards, install the tools required to build `pinctrl` iaw the README:
#
$ sudo apt update
...
$ sudo apt install cmake device-tree-compiler libfdt-dev
...
$ cd utils/pinctrl
$ cmake .
$ make
$ sudo make install
...
#
# You're ready!
#
$ cd
$ pinctrl help
#
# Read the help; there is no man page.

pinctrl provides straightforward support for setting pullup resistors via the pu option; e.g.:

pinctrl -e set 10 pu #Enable GPIO10 ~50k in-pad pull up, echoing the result

pinctrl was developed by the Raspberry Pi team; perhaps in response to the failure of libgpiod & associated "tools" to gain any traction or user acceptance. pinctrl supports the RPi 5, and is a genuinely decent solution in these "unsettled" times of transition (LOL).

You should also be aware of the warning that's displayed when you run pinctrl help (no man page):

WARNING! pinctrl set writes directly to the GPIO control registers ignoring whatever else may be using them (such as Linux drivers) - it is designed as a debug tool, only use it if you know what you are doing and at your own risk!

This is fair warning, but note that "writing directly to GPIO registers" is not, in and of itself, a bad thing... ultimately, that's got to happen to make anything work! Similarly, it's prudent to recognize the possibility of poorly written (or documented) kernel code.

---

Responses to criticisms in the Comments & elsewhere:

Some will criticize the suggestion to use pinctrl (see the comments below & this answer). Fair enough - everyone here is entitled to their opinion. But before making a decision you should weigh up some facts:

1. Is there a risk of bias in the recommendation for pinctrl?

I am not the author of pinctrl, and have no "pride of authorship" in it. I've received no (zero) remuneration for my recommendation. I have no vested interest in pinctrl. My recommendation and my opinion is based solely on my experience with pinctrl, and my experience with, and reading e.g. on "Kent's libgpiod tools". These are the things that have shaped my opinion: there are no better alternatives to pinctrl available in the "kernel code space".

2. Is there any evidence to support disparaging claims of "no protection against contention that can result in unanticipated hardware configurations"?

In a search of RPi SE, and the RPi forums, I could not find a single instance of any such claims.

3. What alternatives to pinctrl are available in the "kernel code space"... are they "better" than pinctrl?

I feel that "better" is in the eyes of the beholder. One might consider the quality of the documentation, and whether or not the user interface seems logical to them. As for me, I did try libgpiod, and made an effort to learn more shortly after ver 2 of libgpiod was released.

4. WRT the claims regarding the libgpiod tools being "suitable for a production environment", see the following post from one of the RPi engineers:

"I'll agree that the fact gpioset requires interaction to quit is a little odd, but it does make some sense due to the normal operation of libgpio being to restore the state of the gpio. These are really only test tools though and should never be used for production code (same as was documented for sysfs gpio usage). Scripting with them makes no sense as there is no guarantee over the state of the GPIO after the app quits."

• Matthew Moller: Great, I’ll take a look at that later.

Answer 2

RPi.GPIO does not work on the Pi5.

As far as I am aware the GPIO sysfs interface has never supported pulls of any kind. Please be aware that the GPIO sysfs interface is deprecated.

Your only choice via the kernel is to use the gpiochip interface.

• Milliways: The OP does not mention RPi.GPIO. Unfortunately GPIO sysfs still exists in kernel 6.6 even though it has changed. There ARE other options - the libgpiod tools and pinctrl (not that I recommend the latter).
• joan: I assumed rpi.gpio was a misspelling of RPi.GPIO. I class gpiod, libgpiod as gpiochip. I didn't mention pinctrl as it does not use the GPIO kernel interface.
• Matthew Moller: @joan Yes, my main grudge with libgpiod/gpiochip is it doesn't support many features, such as pwm. It is also very poorly documented so even if there was pwm, I probably couldn't find it.
• Matthew Moller: @KentGibson I see. Thank you for the assistance