GPIO on Arch Linux ARM for Raspberry Pi 3 (aarch64)

While everyone appears to prefer that you don't, performance is a bit better on 64bit ALARM vs. 32bit for what I'm doing. Also, I get that warm, tingly feeling of running upstream kernel without odd Broadcom or RPi Foundation patches.

That said, a lot of the basic stuff for managing GPIO isn't available. I had to poke for a few days to figure out what's going on, so I thought I'd document it, partially to save other people time, and partially so it's all in one place when I get back to it.


Talking to GPIO

Don't bother with any of the simplified “Arduino-like” libraries for GPIO. Even if there are patches, they don't function very well. Pins in the sysfs GPIO system have an offset in recent kernels, and the usual libraries don't understand it.

I started looking at fixing the library, but the work required was large enough that just polling the sysfs system started to look like the lazier method after all, when lo and behold: sysfs for gpio is deprecated and is being removed next year. In it's place is GPIO chips as a character device. That's nice, but how to I talk to it?

That's the good part. Apparently, the preferred way to talk to it is with a library called libgpiod, which stands for (lib) GPIO Device, and isn't some weird sort of library/daemon stunt like one finds in libvirtd. It is already in AUR so installing it was dead simple. It's apparently super easy to talk to, but it's really new, was only recently accepted as a kernel project, and is still evolving. Also, not much in the way of documentation as I've been able to find.

Well, except for these examples I found. They make it pretty clear that libgpiod is pretty easy to use. Shame I don't speak French. Also the header files turned out to be pretty well documented.

Pull me Up, Pull me Down

One thing libgpiod doesn't handle is built in resistors for pull-up or pull-down operations. I found a recent GitHub thread talking about it, and reading about it was an emotional rollercoaster. Basically, libgpiod dev didn't want to do it because controlling those resistors isn't something generalized in the kernel, and closed the bug. Dev read ladyada's comment, thought “wait, no, that's bad” and is currently thinking about how best to implement it, because using them is totally in the use case of people using pins. That was last month. So, ultimately it's a positive emotional rollercoaster, but in the meantime libgpiod doesn't handle them.

Instead, they added a method of turning them on in /boot/config.txt, and that seems to do the trick quite well. Otherwise it's device tree overlay or register futzing, which just seems like too much work to read a rotary encoder without wimping out and tossing in some other microcontroller.

All for a resistor I'll probably solder in anyway.

Sam Should Stop Looking for A Pinout Image

Because I'm putting it here.

It comes from Microsoft, of all places.

Notes to Self

  • For whatever reason, XFS doesn't work well on an RPi with an SD card.