Enable GPIO in Manjaro

#7

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.
https://iotdk.intel.com/docs/master/mraa/building.html

Did you try compiling mraa again?

@Oli seems to think it works

#8

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.

#9

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.

@spikerguy

#10

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;
#11

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?

#12

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.

#13

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

Could you link me to it? Thanks!

#14

@spikerguy

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

/dts-v1/;
/plugin/;

/ {
    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

#15

here

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

add i2c3 node to the dts itself and try it.

#16

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…

#17

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.

#18

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:

#19

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:

/dts-v1/;

/ {

    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__ {
            gpio-line-names = "GPIOZ_0\0GPIOZ_1\0GPIOZ_2\0GPIOZ_3\0GPIOZ_4\0GPIOZ_5\0GPIOZ_6\0GPIOZ_7\0GPIOZ_8\0GPIOZ_9\0GPIOZ_10\0GPIOZ_11\0GPIOZ_12\0GPIOZ_13\0GPIOZ_14\0GPIOZ_15\0GPIOH_0\0GPIOH_1\0GPIOH_2\0GPIOH_3\0GPIOH_4\0GPIOH_5\0GPIOH_6\0GPIOH_7\0GPIOH_8\0BOOT_0\0BOOT_1\0BOOT_2\0BOOT_3\0BOOT_4\0BOOT_5\0BOOT_6\0BOOT_7\0BOOT_8\0BOOT_9\0BOOT_10\0BOOT_11\0BOOT_12\0BOOT_13\0BOOT_14\0BOOT_15\0GPIOC_0\0GPIOC_1\0GPIOC_2\0GPIOC_3\0GPIOC_4\0GPIOC_5\0GPIOC_6\0GPIOC_7\0GPIOA_0\0GPIOA_1\0GPIOA_2\0GPIOA_3\0GPIOA_4\0GPIOA_5\0GPIOA_6\0GPIOA_7\0GPIOA_8\0GPIOA_9\0GPIOA_10\0GPIOA_11\0GPIOA_12\0GPIOA_13\0GPIOA_14\0GPIOA_15\0GPIOX_0\0GPIOX_1\0GPIOX_2\0GPIOX_3\0GPIOX_4\0GPIOX_5\0GPIOX_6\0GPIOX_7\0GPIOX_8\0GPIOX_9\0GPIOX_10\0GPIOX_11\0GPIOX_12\0GPIOX_13\0GPIOX_14\0GPIOX_15\0GPIOX_16\0GPIOX_17\0GPIOX_18\0GPIOX_19";
        };
    };

    __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.

#20

Works in Monka’s Armbian OOB.

1 Like
#21

Thanks, I’ll take a look. I’ll continue working away at the GPIO interrupt problem

#22

Based on the discussion here: Zero interrupts
it appears that irq mode 3 is not supported for gpio on the Radxa Zero. I’m not sure what your exact requirements are, but you may be able to work around this limitation by polling the gpio pins rather than using them to generate system interrupts. That’s what I ended up doing.

1 Like
#23

Thanks! I came to the same conclusions after reading through the drivers as well and was going to follow up here.

I’m working on a project similar to Guy Dupont’s Spotify iPod build that uses a Raspberry Pi Zero and an iPod clickwheel via GPIO. He has his source code available and I was looking to use libgpiod and the Radxa to interface with a clickwheel. Polling seems to be too inconsistent unfortunately.

#24

I’m not familiar with the click wheel hardware, but if it can be configured to behave the same as a basic rotary encoder, you can probably get acceptable performance with polling if you dial in debouncing parameters.

Alternately, you could stick something like an Arduino Pro Micro between the Radxa board and the clickwheel. There’s some microcontroller code here that might be helpful. Then the Arduino could emulate a USB HID device, so all the Radxa Zero is seeing is a USB keyboard or joystick or something.

That’s what I did in my project (a retro gaming handheld) which has a 4-way directional pad, four face buttons, two shoulder buttons, and two analog thumbsticks. The Arduino handles the inputs from all the buttons and even absurdly granular settings like advanced acceleration curves for the analog sticks, and as far as the Radxa Zero is concerned, it’s merely a generic USB gamepad that “just works” out of the box.

#25

That’s a great idea, thanks. I appreciate the help.

The microcontroller code was used as the source for the Pi implementation! That is the actual source of truth for interfacing with this clickwheel.

I found I could get the polling to work but only if I pinned the CPU with no delay or debounce which is unsustainable obviously and eventually locks up given enough inputs.

The interior of this iPod shell is getting awfully tight with all this hardware ha!

#26

Just to follow up here I ended up using an Adafruit Trinket and everything is working flawlessly. Thanks again for the suggestion!