Enable GPIO in Manjaro


Is there a way to enable GPIO/I2C/PWM, etc in Manjaro? Thank you very much.


1 Like

This would be also important for me to know.

@spikerguy Is the manjaro guy

You can try this

pacman -S base-devel cmake swig json-c python git nodejs
git clone https://github.com/radxa/mraa.git
cd mraa
mkdir build
cd build

See if that builds

sudo make install

1 Like

Thank you this works. But for the right documentation please add a sudo in front of every command for admin rights.

Cool there is also https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/ from the original https://github.com/brgl/libgpiod

Since linux 4.8 the GPIO sysfs interface is deprecated. User space should use
the character device instead. This library encapsulates the ioctl calls and
data structures behind a straightforward API.

With a google

# Add header file missing from Linux user space includes

mkdir -p $curdir/include/linux >> $logfile 2>&1

cp /usr/src/linux-headers-$kerver/include/linux/compiler_types.h $curdir/include/linux/. >> $logfile 2>&1

log "Running autogen"


./autogen.sh --enable-tools=yes --enable-bindings-python --prefix=/usr/local CFLAGS="-I/usr/src/linux-headers-$kerver/include/uapi -I$curdir/include" >> $logfile 2>&1

That allows some pretty cool cli options and because since linux 4.8 the GPIO sysfs interface is deprecated really it shouldn’t be used.


There are currently six command-line tools available:

  • gpiodetect - list all gpiochips present on the system, their names, labels
    and number of GPIO lines

  • gpioinfo - list all lines of specified gpiochips, their names, consumers,
    direction, active state and additional flags

  • gpioget - read values of specified GPIO lines

  • gpioset - set values of specified GPIO lines, potentially keep the lines
    exported and wait until timeout, user input or signal

  • gpiofind - find the gpiochip name and line offset given the line name

  • gpiomon - wait for events on GPIO lines, specify which events to watch,
    how many events to process before exiting or if the events
    should be reported to the console


# Read the value of a single GPIO line.
$ gpioget gpiochip1 23

# Read two values at the same time. Set the active state of the lines
# to low.
$ gpioget --active-low gpiochip1 23 24
1 1

# Set values of two lines, then daemonize and wait for a signal (SIGINT or
# SIGTERM) before releasing them.
$ gpioset --mode=signal --background gpiochip1 23=1 24=0

# Set the value of a single line, then exit immediately. This is useful
# for floating pins.
$ gpioset gpiochip1 23=1

# Find a GPIO line by name.
$ gpiofind "USR-LED-2"
gpiochip1 23

# Toggle a GPIO by name, then wait for the user to press ENTER.
$ gpioset --mode=wait `gpiofind "USR-LED-2"`=1

# Wait for three rising edge events on a single GPIO line, then exit.
$ gpiomon --num-events=3 --rising-edge gpiochip2 3
event:  RISING EDGE offset: 3 timestamp: [    1151.814356387]
event:  RISING EDGE offset: 3 timestamp: [    1151.815449803]
event:  RISING EDGE offset: 3 timestamp: [    1152.091556803]

# Wait for a single falling edge event. Specify a custom output format.
$ gpiomon --format="%e %o %s %n" --falling-edge gpiochip1 4
0 4 1156 615459801

# Pause execution until a single event of any type occurs. Don't print
# anything. Find the line by name.
$ gpiomon --num-events=1 --silent `gpiofind "USR-IN"`

# Monitor multiple lines, exit after the first event.
$ gpiomon --silent --num-events=1 gpiochip0 2 3 5

@jack Shouldn’t https://github.com/radxa/mraa be pushed upstream to https://github.com/eclipse/mraa so its a little easier to maintain for distro’s?

@Oli the pacman needs a sudo and the install but the rest should run as user

1 Like

Thank you very much! Is there any c/c++ library for gpio pins usage for uart and i2c on manjaro?

Dunno haven’t tried as the bootmask button on my 4gb died and my r0.3 512mb never managed to boot, both where r1.3 dunno if latter ones where better.

I presume libmraa as it is a C/ C++ library, libgpiod is just userspace tools replacement for the sysfs interface that I guess at one stage will not exist.
So I am blind and just getting back up to speed with linux as my memory is extremely bad.

The orig Intel documentation has info on compiling and with some mangling presume you can compile.

Did you try compiling mraa again?

@Oli seems to think it works

Unfortunately I didn’t have chance to try since I change to official ubuntu due my lack of knowledge of I2c and uart on manjaro and also my projects heavily depends on mraa. Last time when I compiled mraa on manjaro it gave me error as “multiple definition of gVERSION and gVERSION_SHORT”. More importantly even if mraa can be compiled well on Manjaro I still could not find a way to enable UART and I2C(official wiki has ways on how to enable them on ubuntu but it doesn’t apply to manjaro.).
Maybe @Oli could try to use mraa to see if I2c and UART are usable. Thank you.

The uboot overlays are uboot and the same as soc based not distro but don’t even know if manjaro includes them, presume they are but maybe not.
I think they should be in /boot/overlays if so.


this allowed me to compile on Manjaro: https://github.com/eclipse/mraa/issues/1041

patch mraa/includes/version.h

-const char* gVERSION;
-const char* gVERSION_SHORT;
+extern const char* gVERSION;
+extern const char* gVERSION_SHORT;

Would it be possible to copy the dtbs from ( e.g. meson-g12a-blah-blah&blah) from official image and put them in /boot/dtbs/??? in Manjaro in order to activate?

If it is from the same kernel version then it might work

There is already a patches version from Radxa while I have the pkgbuild on my git too.

What kind of patch? Like an overlay or a patched version of Manjaro?

Could you link me to it? Thanks!


could you take a look at this DTBO that I created to enable I2C3?


/ {
    compatible = "radxa,zero", "amlogic,g12a";

    fragment@0 {
        target = <&i2c3>;
        __overlay__ {
            compatible = "amlogic,meson-axg-i2c";
            status = "okay";
            #address-cells = <0x01>;
            #size-cells = <0x00>;

for some reason it only turns on i2c1 when I run i2cdetect -l


For manjaro this might not work as there is no DTBo support.

add i2c3 node to the dts itself and try it.

I think the overlays work. I tested with the overclocking overlay you mentioned in another post and reverted back to the original .dtb with the overlay.

Also, the I2C interfaces do get found by i2cdetect but they have no data coming through despite pins being utilized. I’m trying to get the PiSugar UPS to work with the Radxa Zero. So far the power is being sent, but the internal service to report on battery levels and other utilities require i2c access. I know that the Radxa might/would have different addresses for the pins but I think if I can detect that something is coming through, that I can identify which hex addresses and modify their app to use those instead.

Maybe you can help me know how to test if the i2c interface is active somehow?
Also, do you know why HDMI comes out as i2c-0? I do a sudo i2cdetect -l and on default .dtb, i2c-0 gets reported and it’s HDMI…

Not sure how you load overlay in Manjaro since they don’t have any official support for it, and I know there is one I2C bus that is always on for HDMI but I don’t remember the bus number. I have a package to load dtbo in Arch/Manjaro here that you can try. Also you need to make sure you compile dtbo with -@ options.

Edited extlinx.conf at /boot/extlinux/ following this: ROCKPro64 Device Tree Overlays on Mainline - PINE64

added my overlay into this field:
FDTOVERLAYS /dtbs/overlays/cpu-overclock.dtbo /dtbs/overlays/i2c-enable.dtbo

yup this is what I’m doing

In any case they don’t seem to work. Doing some tests on Armbian/Focal to leverage the packages ppa's for libmraa as well as uEnv.txt to see if that makes a difference. Might just give up on Manjaro for now until I have more time to figure out how to compile or until there is official GPIO/I2C support…:frowning:

For what it’s worth, I am working on getting GPIO access to work in Manjaro. Step 1 was at least getting some human readable labels in there. I merged this dts with the meson-g12a-radxa-zero.dtb that is set to load by default and I now have the labels:


/ {

    fragment@0 {
        target = <0xffffffff>;

        __overlay__ {
            gpio-line-names = "GPIOAO_0\0GPIOAO_1\0GPIOAO_2\0GPIOAO_3\0GPIOAO_4\0GPIOAO_5\0GPIOAO_6\0GPIOAO_7\0GPIOAO_8\0GPIOAO_9\0GPIOAO_10\0GPIOAO_11\0GPIOE_0\0GPIOE_1\0GPIOE_2";

    fragment@1 {
        target = <0xffffffff>;

        __overlay__ {

    __fixups__ {
        gpio_ao = "/fragment@0:target:0";
        gpio = "/fragment@1:target:0";

Without overlay support it looks like combining with the default dtb is the only way?

Additionally, I am trying to get edge detection working but I get strange behavior. If I export a pin, say GPIOX_10 (587), I see active_low device direction power subsystem uevent value. I have no option for /edge. I can get and set the value and gpioinfo correctly reports in use sysf when exported. gpiomon 0 75 fails with gpiomon: error waiting for events: No such device.

Very long story short, I would love to use Manjaro because I successfully can get widevine working in Chrome and Firefox (widevine-aarch64) and need to work with a device via GPIO. Using Armbian I can at least get rising and falling edge events independently but both edges fail irq mode 3 failed. Additionally I can’t get widevine to load properly.

Works in Monka’s Armbian OOB.

1 Like