In order to switch the fan on or off, the DevTerm scripts appear to use the gpio command, which is part of WiringPi (I think…). Running that command as the default cpi user, or another regular user, results in an error.
On a Raspberry Pi, this is handled by having an OS group called gpio and having the pi user (and other users) as part of that, with the binary using the setuid features. There are udev rules that set the group as owner on the relevant parts of the system device tree.
I’m guessing something similar should be part of the OS setup for the DevTerm?
This is not likely the answer you want but the Q&D solution is to put appropriate commands into /etc/rc.local to export GPIO pins and set permissions on the files. This is what I typically do on all the non-rPi SBCs I use.
Depending on which of GPIO interfaces you choose to use you either need to set permissions on files in /sys/class/gpio or /dev/gpiochip*. With the /sys/class/gpio interface you have to export the pins you want, which will create new gpio[0-9]* directories. Then set permissions on the content of those. In the case of the /dev/gpiochip* interface you just need to set permissions on /dev/gpiochip0.
At least in the case of the /dev/gpiochip devices you can create a udev rule. I don’t have the time at the moment to dig up the device information needed to create the rule. But I’m sure uncle g00gle has some answers. In the case of the older /sys/class/gpio interface I don’t know that udev has anything to do with that. Other than observing that it takes the rPi install time to assign the perms to new exports I’ve never dug further to see how they accomplished it.
In case you don’t know /etc/rc.local is run at boot time. This is why I put the rules there. This makes them persistent. But that said you will need to either run the commands or rc.local manually, as root, or reboot to make them immediately effective.
Of course there are a lot more details. I don’t know your level of experience. I’ll try to get back and answer more questions if my brief explanation doesn’t make sense.
1 Like
All makes sense, thank you! I’m mostly looking to avoid needing to be root to run the gpio command to drive features like the fan, so I’ll need to look at how that calls into the sys tree.
What I’d do is grab the schematic and see which GPIO pins are available, export them all and give permissions on them. I’d exclude ones that other drivers claim, like: SPI, I2C, … unless I’m certain I’m not using those features. If you are looking at Allwinner pin names there is a formula to follow to turn them into Linux pin #s: (lettter-‘A’)*32+number
That means: A0 = 0, A1 = 1, … B0 = 32, B1 = 33, …
There is also the controller base to be considered. It would be added to the result. But in this case its 0, so its inconsequential. The number at the end of the “gpiochip*” name in /sys/class/gpio gives you that value or check the base file within the gpiochip* directory.
So… assuming the GPIO41 listed in the schematic is accurate, from Linux’s perspective, you simply need to echo 41 > /sys/class/gpio/export. That will create the /sys/class/gpio/gpio41 directory and you then need to change owner ship from root to “cpi”, or whichever user you want to bless with the power.
Something like this added to /etc/rc.local would work:
cd /sys/class/gpio
for p in 41
do
echo $p > export
chown -R cpi gpio$p
done
NOTES:
- In this case the
for loop is unnecessary. But it allows you stack as many pins as you like
- The script can also set direction for you if desired. I find this useful since pins typically are only used in one direction for the duration of runtime. But its not necessary since you own it now.
- You could use the
gpio command to setup the pins, then change the ownership. But I hate gratuitous complication and its entirely possible it uses the /dev interface, which may not export the pins in /sys/class/gpio. I’ve not used the gpio or the /dev interface yet. I’ll likely uninstall wiringingpi or whatever its called.
- Normally I put this in its own script named
/etc/gpio and then call it from /etc/rc.local this allows me to call it without needing to execute whatever else I might have in rc.local.
- You can also change ownership on the
export and unexport files but it serves little purpose since newly exported gpio files are owned by “root”.
- I also use this script to set other rights on other I/O devices I’m likely to use: I2C, SPI, UARTs, …
- You can also do that with
udev rules, but: the detail documentation is mostly missing, it turns into time-suck getting it to work, anyone with moderate UNIX experience understands what the script does.
- Like rPi you could assign permissions based on a group.
- You could write this script in whatever other language you prefer.
rPi is nice that they take care of this, for you, with a group. I don’t do much with rPi, they’ve never tripped my trigger. Most of the other boards I’ve worked with are just like DevTerm, leaving it to the board owner to set their perms. I’ve also run into timing issues with rPi where there is a noticeable lag (in terms of clock cycles) between when you export a pin and when you are blessed with access. So for seamless access I usually do all my exports at boot, even on an rPi.
2 Likes
Thanks for this very details set of instructions, and I think long term the “correct” way is to do what you’ve outlined here, keeping things safe and secure.
The DevTerm is more-or-less set up as a single user system and “I am root”, so I’m less concerned especially where I’m currently in a “playground / sandbox / scratch” setup environment. The absolutely quickest solution is chmod +s /usr/bin/gpio (which is what I’ve done to “fix” my fan on/off function, added to my notes), but if we were jointly building a proper distribution then I think using udev and using Linux groups to allocate access is the better approach.
I agree with you. I’m one of the few who have no problem with people running as root on their SBCs. If its yours, your the only one using it and its shielded from the iNet: be free, be “root”! Heck that’s the way it was on my TRS-80 model I. 
When you connect it to the iNet or have other users involved then its time to up your game. And frankly if you’re going to run a modern browser or email client its probably best to not be “root”. 
Sometimes I even question the safety of sudo’ing everything. Especially when passwords are turned off. IMO one of greatest failures with computer security is the idea that one-size-fits-all.
But, yeah, from the “distro maker” standpoint having I/O perms tied to a group and the factory user in that group would be splendid. I’ll have to keep that in mind when I finish debunting my OS seed image.
1 Like