Missing GPIO interfaces

Hi everyone :slight_smile:

I’m running snapd on a Debian Jessie (armhf) and my snap needs to access to the GPIO interface. Unfortunately the core snap does not offer the gpio interface and my daemon is not allowed to write in /sys/class/gpio/*. Interesting here is that /sys/class/pwm/ works perfectly, without interface. Is there any possibility to get access? Any workarounds so I can continue the development?

$ snap version 
snap    2.24
snapd   2.24
series  16
debian  8
kernel  4.4.13

PS: also the serial-port and i2c interface is missing.

note that we only support these interfaces in Ubuntu Core images and expect them to be defined in the gadget snap …

here is an example:

1 Like

As we don’t have hotplug support yet and thus cannot discover them at runtime we rely on all-snap images that use the gadget snap to declare such interfaces statically. As we start working on generic hotplug you can expect to see them work better in classic as well.

Is there any difference between accessing pwm and gpio from the snap perspective? Would a gadget snap on a classic image make sense just for offering the hardware access without the boot part?

Yes, I think they have different sysfs interface. The rule of a thumb is that if the way your software talks to something is different then it is a different interface.

we do not have support for gadget snaps on classic installs (yet) so this is a moot point, it would not work currently …

that said, there is support for gadget snaps planned in the future, and there is the dynamic interfaces that zyga mentioned …
but today, you have to create an all-snap image to get access to these interfaces.

Yes, the sysfs interface is different, but from a security perspective accessing low level hardware I don’t see any difference? Or is the pwm unhandled in the core and that’s the reason why I can use it? Just for understanding/bug finding :slight_smile:

/dev /sys and /proc are just bind-mounted into the core snap, but snapd will still prevent access to them

The security difference is not relevant. If I wrote a motor fan driver that requires PWM and I offer it for general use on any system that has PWM control it doesn’t matter that the particular security language that happens to describe PWM and GPIO is similar. When the user installs my snap they should be offered a choice to connect sensible PWM slots to the plug my snap understands.

That’s a good point and makes sense to me! So building a native ubuntu-core image for my platform would solve the problem using a gadget snap with pwm, uart and gpio definitions.
Is that possible to build an image on ubifs?

I don’t know. I don’t think anyone tried yet. From snapd point of view that’s all fine, as long as the bootloader can mount ubifs and mount stuff from there. You will have to see how the bootloader and snapd interact. Snapd sets bootloader variables and a special boot script in the bootloader, in the gadget snap interacts with those to set up the expected boot behaior.

Challenging :slight_smile: I’ll try!

Just noting that I’ve been able to read and set pi3 GPIO pins from a strict golang snap, and verify it with a voltmeter.

The gadget snap declares them:
interface: gpio
number: 8
interface: gpio
number: 7

The snap declares the gpio plug:
command: gpio
plugs: [ gpio ]

Connect the interfaces like so:
snap connect mysnap:gpio pi3:bcm-gpio-7
snap connect mysnap:gpio pi3:bcm-gpio-8

After which the directories are accessible for programmatic control, for example you can set the pin direction file to "in"or “out” on this path:
path := “/sys/class/gpio/gpio” + pinNum + “/direction”

And set and read the value on this path:
path := “/sys/class/gpio/gpio” + pinNum + “/value”

I used a voltmeter to verify. On the Pi3, one voltmeter connector touches a pi3 ground pin, the other touches the bcm number of the gpio pin, and I see the changing value.

note that we found a small bug with the gpio interface regarding “/sys/class/gpio/export” today though … GPIO on Raspberry Pi 3 not working for blink program has some background …